java高并发需jvm、线程、io、组件与环境整体协同，核心是“稳”和“可预期”；须选jdk 11+、合理调参、隔离线程池、用netty/webflux、保障组件线程安全、调优linux、容器化并启用jfr。
Java高并发应用不是靠单点优化堆出来的，而是从JVM、线程模型、IO机制、基础组件到部署环境整体协同的结果。核心在于“稳”和“可预期”——系统在压力下行为可控，资源不泄漏，响应不雪崩。
选对JVM并合理调参
JVM是Java高并发的底层基石。默认配置完全不适合高负载场景。
- 优先使用JDK 11+（推荐JDK 17 LTS），自带ZGC或Shenandoah等低延迟垃圾收集器，避免CMS或Parallel GC在大堆下的长时间STW
- 堆内存不宜过大（如32GB以内），避免G1退化为Full GC；设置-XX:+UseG1GC -XX:MaxGCPauseMillis=50控制停顿目标
- 启用-XX:+UseStringDeduplication减少字符串重复内存占用，对HTTP请求头、JSON字段多的场景很有效
- 通过-XX:+PrintGCDetails -Xlog:gc*:file=gc.log输出详细GC日志，配合GCViewer或GCEasy做瓶颈定位
用好线程与异步模型
盲目加线程只会加剧竞争和上下文切换开销。关键在“分层隔离”和“非阻塞推进”。
- 业务线程池必须隔离：Web请求、定时任务、消息消费、DB操作各用独立线程池，避免相互拖垮
- 拒绝使用Executors.newFixedThreadPool()——它用无界队列，OOM风险极高；改用new ThreadPoolExecutor(cores, max, keepAlive, new LinkedBlockingQueue(1024))并设拒绝策略为CallerRunsPolicy或自定义降级逻辑
- IO密集型场景优先用Netty或WebFlux替代Servlet容器，默认Tomcat线程模型是阻塞式，吞吐天花板明显
- 慎用ThreadLocal：若未及时remove，可能在长生命周期线程（如线程池）中引发内存泄漏；必要时用TransmittableThreadLocal支持异步传递
夯实基础组件的并发安全性
很多并发问题其实出在“以为线程安全”的错觉上。
立即学习“Java免费学习笔记（深入）”；
- HashMap、ArrayList、SimpleDateFormat等非线程安全类禁止在共享上下文中直接使用；改用ConcurrentHashMap、CopyOnWriteArrayList、DateTimeFormatter（不可变、线程安全）
- 数据库连接池必须用HikariCP（启动快、性能稳、监控全），禁用Druid（功能多但锁粒度粗，高并发下易成瓶颈）；设置minimum-idle=cores、maximum-pool-size=cores×3~5，避免连接争抢
- 缓存统一走Redis + LocalCache两级结构（如Caffeine+Redis），避免缓存击穿；热点Key加随机过期时间，防雪崩
- 分布式场景下，避免用synchronized或ReentrantLock做跨JVM同步；改用Redisson的RLock或ZooKeeper临时节点实现分布式锁，注意看门狗续期和锁失效边界
操作系统与部署环境不能掉链子
再好的Java代码，卡在系统层就全白搭。
- Linux需调优：增大文件描述符限制（ulimit -n 65535）、关闭swap（vm.swappiness=0）、启用TCP快速回收（net.ipv4.tcp_tw_reuse=1）
- JVM进程务必用systemd或supervisord托管，禁止前台运行；添加OOM Killer防护：echo -17 > /proc/$(pidof java)/oom_score_adj
- 容器部署时限制CPU配额（--cpus=2）和内存（-m 2g），并开启JVM容器感知：-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0
- 压测前必须打开JFR（Java Flight Recorder）：-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr，真实复现线程阻塞、锁竞争、GC卡顿等现场
基本上就这些。高并发不是一步登天的事，而是把每个环节的“默认不安全”变成“显式可控”。环境搭得扎实，后续加限流、熔断、分库分表才有意义。
