为什么堆内存调优不是高级操作，而是日常必需
你有没有遇到过这种情况：公司内网部署的Java服务，早上一上班就卡顿，监控显示GC频繁，CPU占用飙高。重启一下又好了，但过几个小时问题重现。这很可能不是代码逻辑的问题，而是堆内存没调好。
很多开发者觉得堆内存调优是“上线前最后一步”或者“运维的事”，其实它和写代码一样，是日常开发的一部分。尤其在资源有限的内网环境中，调得好能省下不少服务器成本，也能避免半夜被报警叫醒。
别盲目设-Xmx，先看真实使用情况
常见误区是直接给JVM设置一个很大的堆，比如 -Xmx4g 或 -Xmx8g，觉得“反正机器有内存，多点不怕”。但大堆不一定好，GC停顿时间可能更长。
正确的做法是先观察应用实际内存使用。可以用 jstat 命令查看GC情况：
jstat -gcutil <pid> 1000看看年轻代、老年代的使用率和GC频率。如果发现老年代增长缓慢，说明对象大多短命，可以适当缩小堆；如果老年代很快填满，就要查是不是有内存泄漏，而不是一味加内存。
合理分配新生代比例，减少Full GC发生
默认情况下，新生代只占堆的1/3左右。但对于大多数Web应用来说，对象大多是请求级别的，生命周期极短。加大新生代比例，能让更多对象在Minor GC中就被回收，避免提前进入老年代。
可以这样设置：
-Xms2g -Xmx2g -Xmn1g -XX:SurvivorRatio=8这里把新生代设为1G，占堆的一半，两个Survivor区各占1/10，Eden占8/10。这样短命对象基本在Young GC中解决，老年代压力小了，Full GC自然少。
选择合适的垃圾回收器
如果应用对延迟敏感，比如API接口服务，建议用G1回收器。它能把GC停顿控制在指定范围内，适合交互式场景。
启动参数示例：
-XX:+UseG1GC -XX:MaxGCPauseMillis=200如果是批处理任务，不那么在意停顿，用Parallel GC吞吐量更高，更适合后台计算。
避免内存泄漏，比调参更重要
再好的调优也扛不住内存泄漏。常见问题是静态集合类持有对象引用，比如用HashMap缓存数据却不限制大小。
换成WeakHashMap或使用Guava Cache这类带过期机制的工具，能有效避免问题：
Cache<String, Object> cache = Caffeine.newBuilder()
.maximumSize(1000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.build();这种细节能从根源减少内存压力。
监控要持续，调优不是一劳永逸
业务量变大、新功能上线都可能影响内存使用模式。建议在内网监控系统里加入GC日志分析，比如用ELK收集GC log，设置阈值告警。
开启GC日志也很简单：
-Xlog:gc*,gc+heap=debug,gc+age=trace:file=gc.log:time,tags日志里能看到对象年龄分布，帮助判断是否需要调整新生代大小或晋升阈值。
堆内存调优不是一次性的技术动作，而是随着业务演进不断优化的过程。尤其是在内网环境，资源不像云上那么灵活，每一分内存都得精打细算。