一、Arrays.asList的陷阱
Arrays.asList是Java中一个非常方便的静态方法，它可以将数组转换为列表（List）。然而，这个转换并非我们直观理解的那样，创建了一个全新的、独立的列表对象。实际上，Arrays.asList返回的列表是一个固定大小的列表，它直接由原始数组支持。这意味着，你不能通过返回的列表来添加或删除元素，因为这样做会尝试修改底层数组的大小，从而抛出ConcurrentModificationException或UnsupportedOperationException。
案例警示：
假设你在一个循环中使用了Arrays.asList转换的列表，并尝试修改它，这很可能导致难以追踪的错误。更糟糕的是，如果你将这个列表作为参数传递给其他方法，并期望对方能够修改它（比如添加元素），那么你会遇到意外的行为。
建议：
- 当你需要一个可变的列表时，请使用
new ArrayList<>(Arrays.asList(...))来创建一个新的列表副本。 - 清晰理解
Arrays.asList的返回类型及其限制，避免在需要动态修改列表的场景下使用。
二、ArrayList.subList的雷区
ArrayList.subList是另一个看似方便实则暗藏危机的方法。它允许你从原列表中提取一个子列表，但这个子列表是原列表的一个视图（view），而非独立的副本。这意味着，对子列表的任何非结构性修改（如设置元素的值）都会反映到原列表上，这是符合预期的。然而，对子列表进行结构性修改（如添加、删除元素）则会导致原列表和子列表同时抛出ConcurrentModificationException，因为子列表的修改没有通过原列表的迭代器进行。
案例警示：
如果你在不了解这一特性的情况下使用subList，并尝试在子列表上进行结构性修改，你的代码将变得脆弱且难以维护。
建议：
- 如果需要修改子列表，并希望这些修改反映到原列表上，确保只进行非结构性修改。
- 如果需要独立的子列表副本，请使用
new ArrayList<>(list.subList(...))来创建。
三、结语
作为CTO，我深知技术选择对项目的重要性。Arrays.asList和ArrayList.subList虽然强大，但它们的特殊行为往往被忽视，从而导致难以调试的错误。因此，我强烈建议团队成员在使用这些方法时保持警惕，深入理解其背后的机制，并根据实际需求做出明智的选择。只有这样，我们才能构建出稳定、高效、可维护的软件系统。
