一个Spring Boot商品报价接口，原本需要处理3000条商品明细：读取价格、计算优惠、转换DTO，再返回给前端。
旧代码用for循环，P99约700ms。Codex看到每条商品似乎独立，便建议改成parallelStream()。
本地测试变快、单测全绿。预发布环境200并发时却出现反转：CPU从35%涨到80%，P99接近1.4秒，其他接口也跟着抖动。
代码没有抛异常，结果数量也对。为什么"并行"反而比"串行"慢？
关键判断： **parallelStream()**只提供并行执行的可能，不承诺任务更快，也不替应用管理数据库、HTTP连接和CPU的整体预算。
一、一行改动，改变的不是语法，而是执行模型
旧代码很直观：
List<Result> results = new ArrayList<>();
for (Product product : products) {
results.add(convert(product));
}Codex改成：
List<Result> results = products.parallelStream()
.map(this::convert)
.toList();Java 16之后，Stream.toList()返回不可修改的List；后续代码若调用add()，就有兼容性风险。普通循环依次执行，并行流则拆分任务、多线程计算再汇总；结果可保序，convert()的执行先后却不固定。
重构前要问：convert()是否独立？单条任务多重？线上有多少空闲资源？
二、第一种原因：单条任务太轻，调度成本超过计算收益
如果convert()只是简单计算和DTO赋值，串行循环的额外开销很低。
并行流需要拆分、调度与汇总任务。它不是每条记录建一个线程，但每项计算很轻时，额外成本可能超过收益。
这里要强调：3000条并不能证明应该并行。 3000次字符串复制和3000次复杂加密计算，完全不是一个量级。正确做法是先剖析热点方法，再判断每项计算的工作量是否足以摊薄调度开销。
按Amdahl定律，如果仅80%的时间可并行，使用4个理想工作单元，忽略额外开销的理论上限也只有1/(0.2+0.8/4)=2.5倍。
实际还会受到任务分配、内存访问和GC等影响。能并行的比例不够高，换多少线程都不可能无限提速。
三、第二种原因：ForkJoinPool.commonPool被不同请求争用
parallelStream()通常使用进程共享的ForkJoinPool.commonPool，并非每个HTTP请求独占；其并行度受JDK、处理器数量和JVM设置影响。
假设线上200个HTTP请求同时执行并行流，它们可能争用公共池中的工作线程；原来的请求线程还在等待并行计算完成。其他使用公共池的任务也可能受到影响。
结果可能是CPU很忙，吞吐没涨，P99反而恶化。
在Kubernetes里，还要检查CPU Limit和节流：Pod只有2核预算，多线程也无法创造额外CPU时间。
同一段代码在开发机变快、在受限容器变慢，并不矛盾。 性能结论必须结合真正的部署资源来判断。
四、第三种原因：map里隐藏了数据库与HTTP调用
真正危险的是convert()里面藏着查询会员价、读Redis或调用促销服务。
串行版本下游请求较平缓；并行后，一个HTTP请求就可能同时发出多次SQL或RPC，多用户叠加很容易撞到连接池或限流上限。
这时主请求的耗时可能不再由计算决定，而是由"等连接""等远程返回"决定。ForkJoinPool适合大量可拆分的计算任务，对于一般阻塞IO并不自动提供可靠的容量管理。即使工作线程被阻塞，也不代表框架一定会为每个阻塞调用扩容补偿。
如果失败再重试，下游压力还会增加。
要让Codex追进convert()内部，查Repository、Feign及其他IO依赖。
只要任务里有远程调用，就需要先设计并发上限、超时和降级，而不是直接把stream改成parallelStream。
五、第四种原因：事务、ThreadLocal和共享对象跨线程失去边界
除了性能，还得检查正确性。
例如某个Service方法带有@Transactional，内部使用并行流做数据查询与更新。Spring常见的事务上下文是绑定线程的，不能假设事务会自动传到并行工作线程。不同线程可能不在同一数据库事务中，使用线程绑定的EntityManager或懒加载实体也可能出现异常行为。
MDC、租户和安全上下文等ThreadLocal也不会天然传播；工作线程可能缺少正确的tenantId。
多个线程写普通ArrayList或非原子计数器，可能悄悄丢数据。
尽量让map()成为纯函数，用归约收集结果；事务和外部写入保持明确边界。
并行优化的验收标准必须包括数据一致性，而不只是耗时。
六、第五种原因：把GC和内存开销也放大了
并行流不必然多分配对象，但若每个分支都产生中间集合或临时对象，GC压力可能上涨。
如果P99恶化时，JFR同时显示分配速率上升、GC Pause增多，或者频繁的对象复制，就需要检查是否引入了多余的中间步骤。
内存带宽和CPU缓存也会争用，因此加线程不保证线性提速。
所以要同时看分配速率、GC和线程状态，区分有效计算与并行开销。
七、怎样用JFR找出真正的瓶颈？
排查顺序不要从"调整并行度"开始，而是先复现同样的数据量和并发负载，再采集证据。
先对比P99、吞吐、错误率和CPU，再用JFR找热点、阻塞、锁、对象分配与GC；容器环境同步看节流、连接池等待和下游QPS。
如果CPU热点集中在数学计算，且没有明显阻塞，说明可以继续评估计算型并行。
如果线程大量阻塞在HTTP、数据库连接获取或同步锁上，优先解决IO或竞争，而不是简单增加线程。
如果CPU热点主要来自对象构造、拆分和归并，就应该重新评估并行任务粒度。
Profile用于确定瓶颈，压测用于判断修复收益；二者不能互相代替。
八、JMH测得快，为什么接口压测仍可能慢？
JMH适合测纯计算，控制预热、JIT和多轮测量；注意避免基准代码被编译器优化掉。
但JMH结果并不能直接代表整个Spring Boot接口：真实接口还有HTTP解析、序列化、线程调度、数据库连接、缓存、远程调用和并发用户。
例如JMH显示纯计算变快，但200并发接口压测因公共池争用而变慢，两者可以同时成立。
实验要固定JDK、CPU限制、数据量与预热条件，多次运行，不以一次最快结果为准。
九、一个可复用的三组对照实验
我更建议按三类真实任务分别实验，而不是把所有循环混成一种情况。
A组：轻量DTO转换。 数据量3000条，只有字段映射和简单条件。重点看并行调度开销是否抵消收益。
B组：纯CPU密集计算。 每条任务独立且计算量足够大，没有外部IO、共享状态或数据库事务。重点比较不同并行度下的吞吐与P99。
C组：包含数据库或HTTP请求。 每条转换还依赖外部服务。重点看下游QPS、连接池等待、超时与重试情况；优先测试批量获取数据而不是盲目并发。
三组都要验证输出数量、排序、金额等关键字段一致。下面这些结果只是用于说明如何判断，不是承诺值：A组串行更快、B组并行收益明显、C组并行后尾延迟更差，都符合合理的工程预期。
接口压测按并发1、20、100、200分档。假设200并发时串行版P99为700ms，并行版1400ms，而吞吐接近，就说明并行没有真正增加处理能力。
若20并发更快、200并发更慢，优先查公共池、CPU节流和下游连接等待；若各档都慢，则查任务粒度和中间对象。
同一个优化在不同并发下出现相反结果，是非常重要的诊断证据。
测试还应校验业务ID、金额、顺序、异常记录，不要只看List长度；"跑得快"也可能只是少做了工作。
十、真正有效的修复，未必是换一个线程池
轻量转换优先保留for循环，减少重复构造和无意义集合拷贝。
数据库N+1优先批量预取：与其并行发3000次SQL，不如先批量查询，再在内存里计算。
纯CPU重任务再评估受控并行，隔离资源并限制并发度。
阻塞IO要单独设计连接池、超时与并发上限；换成CompletableFuture或虚拟线程，也不能凭空增加下游容量。
如果商品报价还依赖会员价，可以先按商品ID批量获取所需价格，整理为只读Map，再执行本地转换。这样下游访问次数被真正减少，也更容易保持事务和请求上下文边界。只有批量预取之后，仍然存在可观的纯计算瓶颈，才继续考虑并行处理这部分计算。
特别要避免在高并发接口里随意创建新线程池：线程池本身需要生命周期管理、队列容量和拒绝策略；对每个请求新建一个池，可能比使用公共池更糟。
优化的重点，是让资源消耗与系统承载能力匹配，而不是把每一段可并行代码都改成并行。
十一、上线前还要检查哪些语义变化？
还要检查排序和异常语义。
parallelStream().map(...).toList()对于有顺序的源通常保留结果顺序，但如果改用无序终端操作、并行forEach，不能再假设副作用会按原来循环的顺序发生。
如果原先单条失败可继续，改造后也要保留失败记录和容错语义。
金额归约要注意浮点加法顺序变化和舍入规则。
所以Code Review不能只问"改完快不快"，还要问：返回顺序、异常行为、事务边界和金额结果有没有被悄悄改变？
十二、给Codex的任务应该怎样描述？
不要只说"改成parallelStream"；应让Codex先列出热点、IO依赖、共享状态、CPU限制和候选方案风险。
保留原实现作基线，局部修改，补充正确性测试，再用JMH、JFR与接口压测决定是否保留。
这也是ChatGPT、Codex更适合的工作方式：AI可以快速生成候选实现，但不能把代码看起来更高级当成完成条件。
十三、Plus和Pro怎么判断？
如果平时只是偶尔让ChatGPT、Codex分析一个循环、检查parallelStream()是否合适、修改一两个热点方法并补测试，Plus通常够用。
如果日常需要连续分析大型Java服务的JFR、线程栈、GC、数据库与RPC指标，跨多个模块改代码，反复执行JMH和高并发回归，任务长、轮次多、使用频繁，那么Pro更适合这样的工程工作流。
关键不在于用了多少线程，而在于实际任务范围、验证轮次和使用额度。更高套餐也不能替代真实压测和正确性检查。
最后
Java把for循环改成parallelStream，为什么CPU更高、接口反而更慢？
因为并行化减少的是某部分串行等待，却会增加任务协调、资源竞争和潜在的并发负载。任务太轻、公共线程池拥挤、map内部阻塞IO、事务上下文丢失或者GC压力上升，都可能让"并行优化"变成性能回退。
正确的顺序应是：定位热点 → 判断CPU还是IO → 检查线程与上下文 → 选择有限并行或批量化 → 基准测试 → 真实负载压测 → 验证业务结果。
真正成功的优化，不是CPU跑得更忙，而是用户请求更快、系统吞吐更稳，同时每一条结果仍然正确。
持续分享 Codex、大模型开发与 AI 编程实战内容
也整理了稳定的 Plus/Pro 会员订阅渠道，有需要可自取。