公司新上的管理系统跑了一阵子，突然发现服务器内存飙到90%以上，一查进程，Java程序占了大头。这种情况不少见，尤其是用Spring Boot这类框架开发的后台服务，动不动就几百MB甚至上GB的内存占用，让人心里打鼓：是不是哪里出问题了？
先别慌，Java吃内存是常态
很多人看到Java程序内存占用高就紧张，其实得看情况。JVM默认会尽可能多地申请内存，为的是减少GC频率，提升运行效率。比如一个Spring Boot应用，刚启动可能就占500MB，但这不等于它真的“浪费”了这么多。可以通过参数控制最大堆内存，避免无限制扩张。
怎么查看Java到底用了多少内存
最简单的办法是用jps找到Java进程ID，再用jstat看看内存使用情况：
jps
jstat -gc <pid>输出里的OGC（老年代容量）、OC（老年代最大容量）和OU（已使用老年代）能看出实际占用。如果OU远小于OC，说明还有余量，不用太担心。
设置合理的JVM内存参数
很多Java程序直接用默认配置启动，这样在生产环境容易出问题。建议明确设置堆内存大小，比如：
java -Xms512m -Xmx1024m -jar myapp.jar这里-Xms是初始堆内存，-Xmx是最大堆内存。根据服务器实际资源调整，避免“吃太多”也防止“不够用”。
检查有没有内存泄漏
如果内存一直涨不降，重启后又慢慢爬升，那可能是内存泄漏。常见原因是静态集合类持有对象不释放，比如缓存没设上限：
public class CacheUtil {
private static Map<String, Object> cache = new HashMap<>();
public static void put(String key, Object value) {
cache.put(key, value);
}
}这种写法长期运行会导致内存越积越多。改用ConcurrentHashMap配合定时清理，或者引入Guava Cache这类带过期机制的工具更安全。
生成堆转储文件分析具体对象
怀疑有大对象占内存时，可以手动触发一次堆转储：
jmap -dump:format=b,file=heap.hprof <pid>然后用Eclipse MAT或JVisualVM打开heap.hprof，看哪些类实例最多、占用空间最大。常会发现字符串、字节数组或日志缓冲区成了“大户”。
日志和第三方库也可能偷偷吃内存
有些项目开了DEBUG级别日志，又用Logback记录到内存队列，流量一大日志堆积，直接把内存撑爆。还有像处理Excel的POI库，读大文件时会把整张表加载进内存，几MB的文件可能产生上百MB的对象。
这时候要么改成分块读取，要么调小日志保留数量，避免雪崩。
容器环境下更要精打细算
现在很多Java应用跑在Docker里，但JVM并不知道自己在容器中，默认按宿主机内存算最大堆。结果就是分配了8G内存，而容器只给了2G，系统开始杀进程。
解决办法是加上识别容器的参数：
java -XX:+UseContainerSupport -Xmx1g -jar app.jar让JVM自动适配容器限制，更稳妥。