并行流处理IO任务时易因共用ForkJoinPool.commonPool()且线程被阻塞而假并行，表现为大量WAITING线程、高await值及串行反而更快；应改用自定义线程池并优化文件读取方式。
并行流本身不直接操作文件系统，但当它被用于处理大量文件读写、IO密集型任务（比如批量解析日志、压缩解压、序列化反序列化等）时，极易暴露底层资源争用问题。核心矛盾在于：并行流默认复用 JVM 全局的 ForkJoinPool.commonPool()，而该线程池大小由 CPU 核数决定（如 2 核机器只有 2 个并行线程），一旦任务中混入阻塞式 IO，线程就会卡在等待磁盘响应上，导致整个池“瘫痪”，进而拖慢甚至阻塞主线程和其他业务线程。
看线程状态是否集体 WAITING
这是最直接的信号。用 jstack <pid> 抓取线程快照后，重点搜索：
- 大量线程停留在 java.util.stream.ForEachOps$ForEachOp$OfRef.accept 或类似 parallelStream 内部调用栈
- 线程状态为 WAITING (on object monitor) 或 TIMED_WAITING，且堆栈末尾指向 FileInputStream.read、BufferedReader.readLine、Files.lines 等 IO 方法
这说明并行流线程正在同步等待磁盘返回数据，而 commonPool 已无空闲线程可用，新来的 parallelStream 调用只能排队或阻塞。
查磁盘 I/O 实际负载
不要只看 CPU 使用率低就排除 IO 瓶颈。执行：
- iostat -x 1：关注 %util（接近 100% 表示磁盘饱和）、await（平均每次 I/O 耗时，持续 >10ms 值得警惕）、r/s 和 w/s（实际每秒读写请求数）
- iotop -oP：确认是不是你的 Java 进程在发起高频率小块读写（如逐行读大文件），这类模式极易触发随机 IO，放大延迟
特别注意：即使 iostat 显示 %util 不高，若 await 很高且 r/w 频次低，可能是单次 IO 请求过大（如 mmap 大文件）或磁盘响应缓慢（坏道、RAID 同步延迟等）。
验证并行流是否成了串行瓶颈
并行流在 IO 场景下常“假并行、真串行”。做两个对比实验：
- 将 list.parallelStream().forEach(...) 改为 list.forEach(...)（纯串行），观察整体耗时和线程阻塞情况是否反而下降
- 改用显式线程池 + CompletableFuture.supplyAsync(..., customPool)，自定义一个带足够线程数（如 32）的 newFixedThreadPool，对比吞吐变化
如果串行更快，或自定义池明显提升，基本可断定是 commonPool 规模不足 + IO 阻塞共同导致的伪并行陷阱。
检查文件系统与缓存行为
Java 的文件操作高度依赖 OS 层缓存策略：
- 用 cat /proc/meminfo | grep -i "cached\|buffers" 查看页缓存占用。若缓存充足但 await 仍高，说明请求绕过了缓存（如使用 FileChannel.open(..., NOCACHE)）或文件太大无法缓存
- 对同一目录高频创建/删除小文件，可能触发 ext4/XFS 的 inode 缓存压力，用 df -i 检查 inodes 是否耗尽
- 避免在 parallelStream 中反复打开/关闭文件句柄——每个线程都新建 FileInputStream 会加剧内核文件表竞争，应提前预加载或用 NIO 的 Files.readAllLines 批量读取
不复杂但容易忽略
