Java集合框架常见异常及处理方法

答案是通过防御性编程、正确选择集合类型、使用泛型和迭代器等手段可有效避免Java集合异常。具体包括：操作前检查null和索引，使用Optional处理可能为空的对象；遍历时用Iterator.remove()或removeIf()避免ConcurrentModificationException；多线程场景选用ConcurrentHashMap或CopyOnWriteArrayList；禁止修改不可变集合如List.of()返回的实例；始终使用泛型防止ClassCastException，杜绝原始类型以确保类型安全。

Java集合框架中的异常处理，说到底，更多是一种防御性编程的艺术，而不是单纯地用try-catch把所有问题包裹起来。在我看来，真正有效的处理方法，是预判、是规避，是选择合适的工具，而不是等到异常抛出才去“救火”。核心思想就是：尽可能在编译期或运行时早期发现并阻止潜在的问题，而不是让程序在运行时崩溃。

解决方案

处理Java集合框架中的异常，我们通常会遇到几类“老朋友”：NullPointerException、IndexOutOfBoundsException、UnsupportedOperationException、ConcurrentModificationException，偶尔还有ClassCastException。面对它们，我的策略是：

1. 前置条件检查与防御性编程： 这是最基础也最重要的。在操作集合前，先检查集合本身是否为null，要添加的元素是否为null，索引是否越界。比如，if (list != null && !list.isEmpty()) 这样的判断，远比直接操作后捕获NullPointerException来得优雅和高效。对于List，在访问元素前检查索引 if (index >= 0 && index < list.size()) 是基本操作。
2. 选择合适的集合实现： Java提供了丰富的集合类型，每种都有其设计目的。例如，如果你预见到多线程环境下的并发修改，就应该考虑使用java.util.concurrent包下的集合，如ConcurrentHashMap或CopyOnWriteArrayList，而不是简单地给ArrayList加synchronized，那样效率往往不理想，而且还可能因为迭代器机制触发ConcurrentModificationException。
3. 理解并利用迭代器： 当你需要遍历并修改集合时，Iterator接口的remove()方法是唯一安全的集合修改方式（对于非并发集合）。直接在增强型for循环中调用集合的remove()或add()方法，几乎必然会遇到ConcurrentModificationException。
4. 善用泛型： 这几乎是预防ClassCastException的银弹。在声明集合时就明确其元素类型，编译器会帮你检查类型兼容性，将运行时错误提前到编译时，这大大提升了代码的健壮性。
5. 警惕不可变集合： Collections.unmodifiableList()、List.of()、Set.of()等方法返回的集合是不可变的。任何试图修改它们的操作都会抛出UnsupportedOperationException。这并非错误，而是设计使然。在使用这些集合时，要清楚它们的特性，避免不必要的修改尝试。

如何在Java集合操作中有效避免NullPointerException？

NullPointerException（NPE），这东西在Java里简直是噩梦，尤其是在集合操作中。它就像一个隐形的陷阱，你稍不留神就踩进去，然后程序就“砰”地一声炸了。我个人觉得，避免NPE，主要得靠“防患于未然”和“思维定式”的转变。

首先，最直接的办法就是显式检查。每次从Map里取值，或者对一个可能为空的集合进行操作前，都习惯性地加个null判断。比如：

Map<String, String> myMap = getSomeMap();
if (myMap != null) {
    String value = myMap.get("key");
    if (value != null) {
        // 对value进行操作
    }
}

这虽然看起来有点啰嗦，但在关键路径上，它是最稳妥的。当然，Java 8 引入的Optional是个好东西，它能让你的代码更具表达力，也强制你思考null的情况：

Optional.ofNullable(getSomeMap())
        .map(map -> map.get("key"))
        .ifPresent(value -> {
            // 对value进行操作
        });

用Optional的好处是，它把对null的检查和后续操作链式化了，避免了层层嵌套的if。

其次，防御性地处理输入。如果你的方法接收一个集合作为参数，而你又不确定调用方会不会传null进来，那么在方法内部做个检查是很有必要的。

public void processCollection(List<String> data) {
    if (data == null) {
        // 可以抛出IllegalArgumentException，或者创建一个空列表，或者直接返回
        System.out.println("Input data is null, skipping processing.");
        return;
    }
    // ... 对data进行操作
}

甚至，如果你要往集合里添加元素，但又不允许添加null，可以利用Objects.requireNonNull()：

List<String> names = new ArrayList<>();
names.add(Objects.requireNonNull(name, "Name cannot be null"));

这会在name为null时立即抛出NullPointerException，比你后期在某个不相关的操作中才发现问题要好得多。说实话，NPE很多时候是代码设计上的疏忽，而不是运行时环境的不可控因素。养成这种“非空即用”的习惯，会大大减少你调试NPE的时间。

处理Java集合并发修改异常（ConcurrentModificationException）有哪些最佳实践？

ConcurrentModificationException（CME），这个异常的名字就很有意思，“并发修改异常”。它不是一个真正的并发问题，而是一个“fail-fast”机制的产物，意思是“我发现你在我迭代的时候动了我的结构，所以我立马报错，让你知道有问题”。它主要发生在单线程环境下，当你使用迭代器（包括增强型for循环）遍历一个集合时，同时又通过集合自身的add()、remove()等方法修改了集合的结构。

要处理CME，关键在于理解它的触发机制，然后选择正确的工具。

1. 理解“fail-fast”： 大多数java.util包下的集合（比如ArrayList, HashMap）的迭代器都是“fail-fast”的。它们内部维护一个modCount计数器，每次集合结构性修改（添加、删除元素，不包括set元素）都会增加这个计数器。迭代器在每次操作前会检查这个计数器是否与创建时一致，不一致就抛CME。

2. 安全地遍历并修改：

   • 使用迭代器自身的remove()方法： 如果你需要在遍历时删除元素，这是唯一安全的做法。

     List<String> list = new ArrayList<>(Arrays.asList("a", "b", "c", "d"));
     Iterator<String> iterator = list.iterator();
     while (iterator.hasNext()) {
         String element = iterator.next();
         if ("b".equals(element)) {
             iterator.remove(); // 安全删除
         }
     }
     System.out.println(list); // 输出: [a, c, d]

   • 遍历副本： 如果你需要进行添加或更复杂的修改，最简单粗暴但有效的方法是遍历集合的一个副本。

     List<String> originalList = new ArrayList<>(Arrays.asList("a", "b", "c"));
     for (String element : new ArrayList<>(originalList)) { // 遍历副本
         if ("b".equals(element)) {
             originalList.add("x"); // 修改原列表，不会触发CME
         }
     }
     System.out.println(originalList); // 输出: [a, b, c, x]

   • Java 8 removeIf()： 对于删除操作，Java 8 提供了removeIf()方法，它内部实现了安全的迭代和删除。

     List<String> list = new ArrayList<>(Arrays.asList("a", "b", "c", "d"));
     list.removeIf(element -> "b".equals(element));
     System.out.println(list); // 输出: [a, c, d]

3. 使用并发集合： 在多线程环境下，如果你确实需要并发地读写集合，那么java.util.concurrent包下的集合是首选。

   • CopyOnWriteArrayList和CopyOnWriteArraySet：它们在修改时会创建底层数组的副本，因此迭代器遍历的是旧的副本，不会受修改影响，也不会抛CME。缺点是写操作开销大，适用于读多写少的场景。

   • ConcurrentHashMap：提供线程安全的哈希表实现，其迭代器是弱一致性的，不会抛CME，但可能不会反映迭代器创建之后的所有修改。

   • Collections.synchronizedList()/synchronizedMap()：这些方法可以包装非线程安全的集合，提供同步访问。但要注意，它们的迭代器仍然是“fail-fast”的，如果你在迭代时修改，仍然会抛CME，所以你需要手动同步迭代块：

     List<String> syncList = Collections.synchronizedList(new ArrayList<>());
     // ... 添加元素
     synchronized (syncList) { // 必须同步迭代块
         for (String element : syncList) {
             // ...
         }
     }

在我看来，CME的出现，很多时候是设计者没有充分考虑到集合的生命周期和并发访问模式。选择正确的集合类型，或者在迭代时使用正确的方法，是避免这个问题的根本。

Java集合框架中UnsupportedOperationException和ClassCastException的常见场景与预防措施？

这两种异常，一个代表着“我不想干这活儿”，另一个则是“你给我的东西不对付”。它们不像NPE那么频繁，但一旦出现，往往意味着你对集合的特性或者类型系统理解上有些偏差。

UnsupportedOperationException（不支持的操作异常）

这个异常通常发生在当你试图对一个不可修改的集合执行修改操作时。这并非一个错误，而是集合设计者明确告诉你：“这个集合就是用来读的，你别想改它。”

常见场景：

1. Collections.unmodifiableList()、unmodifiableSet()、unmodifiableMap()等方法返回的集合： 这些方法是用来创建只读视图的。任何对其调用add()、remove()、set()等修改操作，都会抛出此异常。

   List<String> original = new ArrayList<>(Arrays.asList("a", "b"));
   List<String> unmodifiableList = Collections.unmodifiableList(original);
   // unmodifiableList.add("c"); // 抛出 UnsupportedOperationException

2. Arrays.asList()返回的List： 这个方法返回的List是基于数组的，其大小是固定的。你不能对其进行add()或remove()操作。

   List<String> fixedSizeList = Arrays.asList("x", "y");
   // fixedSizeList.add("z"); // 抛出 UnsupportedOperationException
   fixedSizeList.set(0, "a"); // 可以修改元素，但不能改变大小

3. Java 9+ 的工厂方法：List.of()、Set.of()、Map.of()等： 这些方法创建的集合是真正意义上的不可变集合，它们的大小和内容都不能改变。

   List<String> immutableList = List.of("apple", "banana");
   // immutableList.add("orange"); // 抛出 UnsupportedOperationException

预防措施：

• 明确集合的修改能力： 在获取或创建集合时，要清楚它是否支持修改。如果需要修改，就不要使用不可变集合或只读视图。
• 防御性复制： 如果你接收到一个可能来自外部的集合，并且你需要对其进行修改，但又不确定它是否可修改，那么最好先创建一个可修改的副本：

  List<String> externalList = getSomeList(); // 可能是一个不可修改的List
  List<String> mutableCopy = new ArrayList<>(externalList);
  mutableCopy.add("new element"); // 现在可以安全修改了

ClassCastException（类转换异常）

这个异常意味着你试图将一个对象强制转换为它实际上不是的类型。在集合框架中，它主要与泛型的缺失或误用有关。

常见场景：

1. 使用原始类型（Raw Types）： 在Java 5之前，集合没有泛型。如果你在现代Java代码中仍然使用List list = new ArrayList();这样的原始类型，那么编译器无法帮你检查类型，运行时就可能出现问题。

   List rawList = new ArrayList();
   rawList.add("Hello");
   rawList.add(123); // 编译器不报错
   
   // ... 稍后
   String s = (String) rawList.get(1); // 运行时抛出 ClassCastException: Integer cannot be cast to String

2. 类型擦除的陷阱（较少见，更高级）： 泛型在运行时会被擦除，这在某些反射或特殊场景下可能导致意外。但对于日常的集合使用，只要正确声明泛型，通常不会遇到这个问题。

预防措施：

• 始终使用泛型： 这是最重要、最有效的预防措施。在声明和使用集合时，明确指定其元素类型。

  List<String> typedList = new ArrayList<>();
  typedList.add("Hello");
  // typedList.add(123); // 编译时报错，完美！
  String s = typedList.get(0); // 无需强制转换，类型安全

• 避免原始类型： 除非是在与遗留代码交互，或者有非常明确的理由，否则请不要使用原始类型。
• 谨慎处理异构集合（Heterogeneous Collections）： 如果你确实需要一个存储多种不同类型对象的集合，可以考虑使用List<Object>，并在取出时通过instanceof进行类型检查，然后安全地进行强制转换。但这通常不是一个好的设计。

在我看来，UnsupportedOperationException提醒我们尊重API设计，而ClassCastException则强调了类型安全的重要性。正确地使用泛型，理解集合的修改特性，能够让你的代码在面对这些“小插曲”时，更加从容不迫。