可伸缩性指资源线性增长时吞吐量能否近似线性提升；瓶颈常在共享状态竞争而非线程数，需通过降低锁粒度、选用LongAdder/ThreadLocal/环形缓冲区等优化；线程池须按任务类型显式配置并监控活跃线程、队列深度及GC停顿。
可伸缩性不是“加线程就变快”
很多人看到并发性能瓶颈，第一反应是增加线程数——结果 ThreadPoolExecutor 的 corePoolSize 越调越大，吞吐反而下降，CPU 使用率飙高但 QPS 上不去。这是因为可伸缩性本质是「系统在资源（CPU、内存、IO）线性增长时，吞吐量能否近似线性增长」。Java 并发中真正卡脖子的往往不是线程数，而是共享状态的竞争：比如多个线程反复争抢同一个 synchronized 块、频繁调用 ConcurrentHashMap 的全局段锁（老版本）、或过度依赖 AtomicInteger.incrementAndGet() 在高争用场景下引发的 CAS 自旋风暴。
从锁粒度到无锁结构：关键取舍点
提升可伸缩性的核心动作是降低同步开销。这需要根据数据访问模式做具体选择：
- 若操作的是独立键值对（如用户会话缓存），优先用
ConcurrentHashMap，但注意 JDK 8+ 已改用Node分段 +synchronized锁单个桶，比 JDK 7 的Segment更轻量； - 若需原子计数且更新热点集中（如全局请求计数器），
LongAdder比AtomicLong更合适——它通过分槽（cells）分散写竞争，读时再合并，代价是最终一致性（不保证实时精确）； - 若业务允许延迟可见性（如统计类指标），考虑用
ThreadLocal避免跨线程同步，但必须手动remove()防止内存泄漏； - 对高频写+低频读的场景（如日志缓冲区），环形缓冲区（
Disruptor模式）比阻塞队列更高效，但开发成本高，需权衡。
线程池配置不是拍脑袋填数字
Executors.newFixedThreadPool(n) 这类快捷方法隐藏了太多风险：拒绝策略默认抛 RejectedExecutionException，队列无限大导致 OOM，线程数固定无法适配负载波动。实际生产中应显式构造 ThreadPoolExecutor，并按任务类型区分池子：
- CPU 密集型任务：线程数 ≈
Runtime.getRuntime().availableProcessors()，避免上下文切换开销； - IO 密集型任务（如 HTTP 调用）：线程数可设为 CPU 数 ×（1 + 平均等待时间 / 平均工作时间），但更稳妥的是压测后定值，并配
LinkedBlockingQueue限长 +CallerRunsPolicy作熔断； - 绝不共用一个大池子处理 DB 查询和图片压缩——慢任务会拖垮快任务的响应延迟。
监控盲区比代码缺陷更危险
没有监控的可伸缩性优化等于蒙眼调参。重点盯住三个指标：
立即学习“Java免费学习笔记（深入）”；
-
ThreadPoolExecutor的getActiveCount()和getQueue().size()—— 若长期接近maximumPoolSize且队列积压，说明任务处理能力已饱和； - JVM GC 日志中的
concurrent phase time（G1/CMS）—— 并发收集器本身也争抢 CPU，高并发下 GC 停顿可能放大成雪崩； -
Unsafe.park()调用次数（通过 async-profiler 抓取）—— 过多线程在锁上挂起，直接暴露争用热点。
这些信号不会出现在单元测试里，只在真实流量下浮现。最常被忽略的是「连接池 + 线程池」的耦合效应：DB 连接数设为 20，却配了 50 个线程，结果大量线程卡在 getConnection() 的阻塞等待上，看起来像 CPU 不够，其实是资源错配。
