盯着生产环境的Full GC日志发呆时脑子里蹦出来的第一个念头往往是“把堆调大”我劝你先把鼠标放下。性能优化真正的第一课不是学会堆参数而是学会反问慢在哪里延迟发生在CPU、内存、I/O还是外部依赖把-Xmx推到32G很容易可代码里隐藏的百万次字符串拼接和一次循环里跑了半天的正则匹配才是真凶。90%的Java性能问题都出在业务代码的坏味道上而不是JVM本身。因此这篇不谈玄学堆调优而是一层一层拆开业务代码、并发控制、I/O模型、JVM配置与数据访问链路。你不需要先成为JVM学家只需要找到离你最近的切入点把慢变成可见、可拆解、可验证的数字。定位慢测量先于调优没有性能数字就动手是很多Java程序员踩得最惨的坑。你会直觉地认为某个接口是GC问题但profiler采样很可能告诉你90%的时间浪费在一把数据库连接池的锁等待上。不同问题对应不同解法所以先启动一个采样器在压测前给JIT足够的预热并确保测试代码里没有可被JIT优化掉的死循环。没有准确测量的优化是自我安慰而伪造测量是职业自杀。更实用的做法是给业务接口加追踪标记把一次请求从入口到数据库的耗时拆成CPU时间、本地锁等待、网络RTT和GC暂停四段。看到分段后你自然知道瓶颈到底堆在哪一段而不是围着JVM参数瞎转。测量到位之后还有一条原则贯穿所有优化任何改动能否上线都要回到同样温度下的AB对比结果来说话。对象分配GC压力的源头Java开发者早已习惯随手new对象的快乐可快乐是要还的。所有创建出的对象都会在某个时刻被回收回收成本不发生在你创建时却会在请求高峰期集中爆发。每减少一次无谓的对象分配就等于少欠GC一次人情。实用的切入点显而易见循环内拼接字符串用StringBuilder组装日志前先判断级别用LongAdder或基本类型数组替代包装类型做统计给HashMap设定合理初始容量时也能避免数十万次扩容带来的数组拷贝与重哈希。控制分配频率比控制单个对象大小更有效因为Young GC触发次数直接由分配速率决定。若是新生代频繁Minor GC而老年代平静请先去代码里降低对象产量而不是把新生代调大——调大新生代只能延缓痛感不能消除病根。锁和并发粒度与结构决定一切并发场景的卡顿大多不是线程数不够而是锁在暗处形成了串联。某个临界区持锁后调用远程服务等于让所有请求排成单列等待网络返回。正确手段是先把临界区缩到最小只保护共享写变量把I/O挪到锁外更彻底一点用读写锁、乐观锁、原子变量或LongAdder拆散热点。同步不是病锁的粒度和共享范围才决定生死。线程池参数也不能拍脑袋定死CPU密集型任务的核心线程数接近核数而I/O密集型必须按阻塞系数放大。很多人把无界队列当成避免线程饱和的免死金牌可流量高峰期无界队列会变成内存炸弹。线程池的队列长度同样需要压测让任务等待被拒绝比等待到内存耗尽更有尊严。ThreadLocal在线程池复用时的值污染老代码经常踩释放时务必remove。I/O模型等待是最大的浪费早期的BIO模型里一个线程死等一个Socket连接连接数一高线程数跟着失控。NIO和Reactor模型的本质不是修复Java而是让少量线程管理大量连接业务线程只处理已经就绪的数据。I/O等待是性能的隐形黑洞你永远计算不出一次错过中断的代价。文件传输更要摆脱手工搬砖——从FileChannel到SocketChannel默认数据会穿过内核缓冲区和用户缓冲区两次拷贝调用transferTo让内核直接搬数据CPU占用能明显下降。缓冲区大小也要实测不是越大越好设置32KiB还是1MiB由数据块长度和网络MTU共同决定。批量思想同样适用于写日志和发消息把零散的小数据攒成一包再发送系统调用次数急剧减少吞吐自然好看。别让你的线程空转等数据而是让数据准备好了再叫醒线程。微小的循环与算法别让CPU空转把调优视线放到代码最深处你会发现许多所谓“慢接口”的死因是一段不起眼的循环。ArrayList的get(i)很便宜可遇到LinkedList就是遍历半个链表HashMap在冲突严重时退化成链表一组特殊字符串就能把QPS打到谷底正则表达式碰上灾难性回溯足够让整台服务器喘不过气。复杂度是性能的硬锚点O(n²)哪怕写得再优雅也是灾难。选择合适的数据结构比任何编译期魔法都直接。Stream API用起来舒服但每次collect都会创建中间容器热路径上真正该追求的是尽量减少中间状态。先判断数据规模再决定排序或去重策略是一个低成本习惯。性能优化的精髓就是让循环最深处每一条指令都产出价值不被无谓的对象和分支绊住。JVM调优让它当替罪羊还是定海神针JVM参数往往是性能话题中最高潮的部分但顺序通常反了应该先优化业务后折腾JVM。在Web服务里GC调优能带来的收益远不如清理一次N1或修复一把锁引起的阻塞。动手前要读GC日志看看对象晋升速度、老年代占用曲线以及Full GC停顿然后决定要不要换GC算法比如从Parallel到G1还是把G1的Region大小和混合回收周期调得更贴合现状。G1适合对停顿有要求的在线服务追求极致吞吐的离线任务反而更适合Parallel。堆大小并非万能药GC停顿不消除内存越多只会让延迟雪崩越惨。调完堆后必须盯着P99和TP999而不是平均耗时。调参前读GC日志调参后看延迟分位数否则你只是在掷骰子。数据库与缓存程序之外的性能黑洞很多接口延迟过高的根子埋在数据库往返里Java代码本身可能只是躺枪。N1查询是持久层最经典的灾难先查出主记录再进入for循环逐条查询子表100条主数据就能产生101次网络往返。把循环查询重构成一次join或批量in延迟可从秒级降到毫秒级。性能瓶颈往往在进程之外数据库和网络的每次往返都在偷走你的P99。连接池同样有最佳区间不是越大越好数据库能承受的并发连接有限超大连接池只会带来无意义的上下文切换。批量写、批量提交、批量更新都是同一套优化哲学。缓存要放在离调用方最近的位置但必须设计空值缓存、过期错峰和降级方案热点key一旦失效所有请求会像洪水一样穿过缓存直达数据库击穿故障就是这么来的。缓存不是万能钥匙没有兜底方案的缓存优化只是一场豪赌。工程质量给每个优化装一个守门员技术人最容易漏掉的切入点是工程规范。你在生产环境辛苦换来的P99改善可能被两周后一段循环里的字符串拼接轻易还了回去。一次成功的性能优化必须靠回归基准与自动化测试来守护。给关键链路埋好性能基线压测脚本进入CI平台P99一旦超过设定阈值就亮红灯。性能问题从不只属于某个高难度时刻它隐藏在每个依赖升级、每个集合初始容量没给够、每段正则表达式的日常增删里。遇到Full GC理想的反应不再是“调大堆”而是执行属于团队的问题拆解清单测量数据、减少垃圾对象、复查锁、I/O与数据库访问JVM调优放在这些之后。这条路未必性感但没有捷径谁先把慢的细节看清谁就先赢。