ConcurrentHashMap 通过分段锁（Java 8+为单桶CAS+synchronized）提升并发写性能，读操作无锁；避免size()、全量遍历、synchronized方法滥用；优选LongAdder、合理配置线程池、慎用ForkJoinPool。
用 ConcurrentHashMap 替代 HashMap + synchronized
直接加锁 HashMap 是最常见却最伤性能的并发写法。它让所有线程排队串行访问，吞吐量断崖式下跌。
改用 ConcurrentHashMap 后，写操作默认按 segment（Java 8+ 改为 Node 数组分段）加锁，读操作甚至完全无锁——这是性能差异的核心来源。
- Java 8+ 中
ConcurrentHashMap的put使用CAS+synchronized锁单个桶，不是全表锁 - 避免调用
size()：它需要遍历所有 segment，可能触发全局重校验；改用mappingCount()获取近似值 - 不要把它当
Map做频繁的keySet().iterator()全量遍历——迭代器弱一致性，但大量数据下仍可能引发明显延迟
慎用 synchronized 方法，优先考虑 ReentrantLock 或无锁结构
synchronized 方法隐式锁住整个对象，哪怕你只改一个字段，其他无关字段的读写也被阻塞。
ReentrantLock 虽语法稍冗长，但支持超时获取、可中断、公平锁选择，且能和 Condition 配合做精细等待控制。
- 用
lock.tryLock(100, TimeUnit.MILLISECONDS)避免无限等待，尤其在服务链路中防止雪崩 - 对简单计数场景，优先选
LongAdder而非synchronized或AtomicLong：它通过分段累加减少争用，在高并发累加场景下吞吐量常高出 3–5 倍 - 别在
synchronized块里调用外部服务或数据库——锁持有时间不可控，极易拖垮整体并发能力
线程池不是越大越好：ThreadPoolExecutor 参数必须按压测结果调
很多人把 corePoolSize 设成 Runtime.getRuntime().availableProcessors() * 2 就以为万事大吉，实际这仅适用于纯 CPU 密集型任务。
IO 密集型任务（如 HTTP 调用、DB 查询）需要更大线程数来掩盖等待，但盲目堆线程只会加剧上下文切换开销，反而降低吞吐。
- 先用
Arthas或jstack观察线程状态：如果大量线程卡在WAITING或TIMED_WAITING，说明不是线程不够，而是下游慢或锁争用严重 -
keepAliveTime设太短（如 10ms）会导致线程频繁销毁重建；设太长（如 60s）又浪费资源；建议从 60s 开始，根据 GC 日志和线程活跃曲线调整 - 拒绝策略别硬写
AbortPolicy：生产环境推荐自定义策略，记录被拒任务关键参数并报警，而不是静默丢弃
ForkJoinPool 适合分治，但别滥用在简单循环上
ForkJoinPool 的优势在于工作窃取（work-stealing），对递归分治类问题（如归并排序、树形遍历、大规模数组并行处理）效果显著。
但它有固定开销：任务拆分、队列管理、线程唤醒等。对小数据量或简单 for 循环，并行流（parallelStream）反而比手动用 ForkJoinPool 更轻量——因为后者默认复用公共池，容易被其他模块干扰。
- 用
ForkJoinTask.invoke()而非execute()：前者会阻塞等待结果，适合主流程依赖返回值的场景 - 避免在
compute()中抛出未检查异常：它会被包装成ForkJoinTask$RuntimeException，栈信息易丢失，调试困难 - 不要在
ForkJoinPool.commonPool()中执行阻塞 IO：它会拖垮整个 JVM 的并行流，应单独构造专用线程池并传入ForkJoinPool构造函数
并发优化真正的难点不在 API 选择，而在于你能准确判断「瓶颈到底在哪」——是锁粒度？线程闲置？GC 拖累？还是下游依赖卡住？脱离监控和压测谈优化，大概率是在给错误的地方加速。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
