在static初始化方法中使用ParallelStream 可能存在死锁问题

ParallelStream 可能引起阻塞，**核心原因在于它的底层实现和“偷懒”的使用方式之间存在冲突**。

简单来说，它默认使用一个**公共的、线程数有限的线程池**，当多个任务或不当的操作同时竞争这个有限资源时，就容易导致阻塞甚至死锁。

具体来说，有以下几个主要原因：

### 🎯 根本原因：共享的“公共资源池”

`parallelStream` 默认使用 `ForkJoinPool.commonPool()` 这个**全局共享的线程池**。

* **资源有限**：这个池的线程数默认是 `CPU核心数 - 1`。它是为**CPU密集型**计算设计的，不适合大量阻塞操作。
* **竞争激烈**：当应用中多个地方（比如多个请求、多个 `parallelStream` 调用）都使用这个“公共池”时，所有任务都在争抢这有限几个线程，就像好多人都想用同一台ATM机。一旦线程被占满，后续任务就只能排队等待，造成阻塞。

### 🔒 场景一：IO或阻塞操作“占着茅坑”

如果你在 `parallelStream` 里执行了**耗时较长的I/O操作**（比如数据库查询、网络调用、文件读写）或**同步等待**，情况会变得糟糕。

* **资源被独占**：这些操作会让 `ForkJoinPool` 的线程长时间处于阻塞状态，无法释放去处理其他任务。
* **形成“交通堵塞”**：随着更多类似的任务提交，公共池的线程很快全部被阻塞，导致依赖此线程池的所有其他 `parallelStream` 都陷入停滞，整个应用响应变慢。

### 💀 场景二：类初始化时的“死锁”（Class Initialization Deadlock）

这是一个很隐蔽的坑。如果在类的**静态初始化块**或**静态变量初始化**时使用 `parallelStream`，就有可能触发死锁。

* **原理**：类的静态初始化在执行时，会先获取一个“类初始化锁”。`parallelStream` 的并行任务在运行时，可能会触发一些方法调用，这些方法如果又间接依赖这个正在初始化的类，就会去等待“类初始化锁”。
* **结果**：主线程（正持有锁，等待并行任务完成）和 `ForkJoinPool` 的工作线程（等待锁释放，以执行初始化相关代码）相互等待，谁也动不了，最终死锁。OpenJDK官方曾报告过此问题，并建议在静态初始化器中避免使用 `parallelStream`。

### 🔗 场景三：与 `CompletableFuture` 或其他池的“活锁”

一个极端的案例是，当一个外部任务（如 `CompletableFuture` 提交的任务）**也使用同一个 `ForkJoinPool`**，并在其内部再次使用 `parallelStream` 时，可能会发生“活锁”（Livelock）或更隐蔽的阻塞。

* **原理**：这会导致复杂的任务依赖关系。外部任务阻塞等待内部 `parallelStream` 完成，而内部 `parallelStream` 又试图获取同一个 `ForkJoinPool` 中已被外部任务占用的线程。
* **现象**：系统并没有完全“死掉”，但因为核心工作线程被无效占用，任务无法取得进展，表现为长时间的卡顿。有开发者就遇到了因 `CompletableFuture` 和 `parallelStream` 共用池而导致的活锁问题，最终只能通过修改代码，让它们使用不同的线程池来解决。

### 🛠️ 如何避免和解决？

1. **评估场景**：如果是**CPU密集型**任务，且数据量较大，用 `parallelStream` 是合适的。如果是**I/O密集型**或包含阻塞操作，应**避免**使用。
2. **使用自定义线程池**：对于关键的或I/O密集的 `parallelStream`，可以将其提交到一个**自定义的 `ForkJoinPool`** 中执行，避免与公共池冲突。
```java
ForkJoinPool customPool = new ForkJoinPool(10); // 自定义线程数
customPool.submit(() -> {
bigList.parallelStream().forEach(item -> {
// 执行你的I/O或计算任务
});
}).get();
```
3. **替换为 `CompletableFuture`**：对于需要精细控制或包含大量异步I/O的场景，使用 `CompletableFuture` 配合自定义的 `ExecutorService` 通常是更灵活、更健壮的选择。
4. **绝对不要在静态初始化器中使用**：这是一个明确的禁忌，很容易导致死锁。

简单总结，`parallelStream` 是一把“便利的刀”，但它的“刃” (公共池) 是共享且有限的，用在“切菜”(CPU任务)上很顺手，但用在“剁骨头”(IO/阻塞任务)上就容易崩口或卡住。