加8个线程仅提速1.3倍，因串行占比F高，受Amdahl定律限制；F≈0.6时加速比上限约2.1倍；优化关键在识别并减少非必要串行，如拆分依赖、批处理、避免全局锁和日志同步。
为什么加了8个线程，性能只快了1.3倍？
因为程序里有大量必须串行执行的代码——比如日志写入、数据库事务提交、共享变量更新、锁同步块，这些部分哪怕用100个CPU核心也跑不快。Amdahl定律直接告诉你：加速比上限 = 1 / (F + (1-F)/N)，其中F是串行占比，N是线程数。如果F = 0.4（即40%时间卡在串行段），哪怕上32核，理论最大加速比也只有约2.1倍。
- 别盲目堆
Executors.newFixedThreadPool(64)——线程数超过可并行任务数后，只会增加上下文切换开销 - 用
jstack或Arthas查WAITING/BLOCKED线程比例，它往往就是隐性F - 一次HTTP请求中，DB查询+Redis调用+JSON序列化这三步若串行执行，就已贡献了可观的
F，优化要从“拆依赖”入手，不是加线程
怎么快速估算自己代码的串行占比F？
不需要精确测量，用“关键路径法”粗估就行：把一次典型请求拆成原子步骤，标出哪些能并发（如批量查多个服务）、哪些必须等前一步结果（如先校验token再查DB）。所有“等前面”的步骤耗时加起来 ÷ 总耗时，就是近似F。
- 示例：登录流程共500ms ——
verifyToken()（50ms）、loadUser()（100ms）、loadRoles()（80ms）、generateJWT()（20ms）、logLogin()（50ms）。若后三步都依赖loadUser()结果，则串行段至少含这四步，F ≈ (50+100+80+20+50) / 500 = 0.6 -
F > 0.5时，别指望多线程带来质变；优先看能否把loadRoles()和generateJWT()提前到loadUser()异步发起 - JProfiler或async-profiler的火焰图里，连续堆栈深度大、无明显并行分叉的长条，大概率就是高
F区域
Java里哪些写法会悄悄抬高F值？
很多看似“无害”的惯用写法，实际在制造串行瓶颈。它们不报错，但让F远高于你预期。
- 用
synchronized保护整个方法，而非只锁关键字段——synchronized void updateBalance()会让所有账户更新排队，哪怕操作的是不同用户 - 共用一个
ConcurrentHashMap但频繁调用size()或keySet().toArray()——这些操作内部需全局遍历或加锁，破坏并行性 - 用
CountDownLatch.await()等待所有子任务，却在每个子任务里又串行调用三次feignClient——外部并行，内部仍串行，F没降反升 - 日志打在循环体内，且用
log.info("user={} balance={}", u.getId(), u.getBalance())——字符串拼接+同步IO，在高并发下成为隐形锁
当F无法再降低时，还有没有其他路？
有。Amdahl定律管的是“固定问题规模下的加速极限”，但它没说不能换问题规模——这时该看Gustafson定律：增大单次处理的数据量，让并行部分占比自然上升。比如原来每次查1个订单，现在批量查100个，串行开销（如网络建连、SQL解析）被摊薄，F实际下降。
立即学习“Java免费学习笔记（深入）”；
- 把
for (Order o : orders) { process(o); }改成processBatch(orders)，即使内部仍用单线程，只要批处理减少了IO次数，F就变了 - 用
CompletableFuture.allOf()并行拉取10个微服务数据，比串行调用10次快得多——但前提是这10个调用真无依赖，否则只是把串行延迟从“线性叠加”变成“随机阻塞” - 真正难的不是算公式，而是识别哪些串行是业务逻辑强约束（如转账必须先扣减再入账），哪些只是实现惰性（如缓存更新顺序可调整）。后者才是优化主战场
公式里的F从来不是静态数字，它藏在你每行synchronized、每次get()、每个没拆开的for循环里。测它不靠工具，靠问自己一句：这一步，真的非得等上一步做完不可吗？
