定位与修复步骤
第一步，得先搞清楚到底是“内存泄漏”还是“容量不足”。这事儿可不能凭感觉，得看数据。在CentOS上，你可以用jstat -gc 命令观察一下，看看每次Full GC之后，老年代的使用率是不是持续走高，空间怎么也释放不掉。如果确实是只增不减，那泄漏的嫌疑就很大了。
但话说回来，很多情况其实是“虚惊一场”。JVM的默认堆内存设置往往比较保守，比如初始堆可能只有物理内存的1/64，最大堆是1/4。对于一些稍微复杂的应用，默认的128MB堆根本不够用，频繁的GC和内存吃紧，很容易被误判为泄漏。所以，如果发现是容量问题，优先调整JVM参数，然后再深入排查泄漏不迟。
确认了泄漏嫌疑，下一步就是“抓现行”。使用jmap -dump:format=b,file=heap.bin 命令抓取一份堆内存转储文件。这可是关键证据。接着，用Eclipse MAT这样的专业工具打开它，重点查看“Dominator Tree”（支配树）和“Leak Suspects”（泄漏疑点）报告，再结合“Histogram”（直方图）分析，通常就能锁定那些占用内存异常的大对象，并顺着引用链找到根源。
别忘了开启GC日志记录，在启动参数里加上-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log。这份日志能告诉你Full GC发生的频率和每次回收的效果，是判断问题严重性和验证修复效果的重要依据。最后提醒一句，如果条件允许，尽量在测试环境复现和验证，避免对线上服务造成直接影响。
JSP与容器的常见根因与修复
内存泄漏在JSP和Servlet容器环境下，有几个特别常见的“高发区”。
类加载与热部署累积（PermGen/Metaspace 问题）
这算是个经典问题了。应用依赖了大量第三方JAR包，或者频繁进行JSP页面预编译、反复热部署应用，都会导致方法区（JDK 7及之前是PermGen，JDK 8+是Metaspace）像滚雪球一样越滚越大。怎么应对呢？首先，可以考虑把公共的、被多个应用共享的JAR包，放到Tomcat的shared/lib目录下，减少重复加载。其次，根据JDK版本合理设置非堆内存大小：JDK 7用-XX:PermSize和-XX:MaxPermSize；JDK 8+则用-XX:MetaspaceSize和-XX:MaxMetaspaceSize。最后，从根本上减少热部署的频率，考虑采用蓝绿发布等更优雅的部署策略。
Session 未合理失效
在高并发场景下，如果Session的超时时间设置得过长，或者根本就没失效，那么大量用户会话对象就会一直驻留在内存里。建议从两方面入手：第一，在那些不需要会话状态的JSP页面头部，加上<%@ page session=“false” %>指令，直接禁用Session创建。第二，在web.xml中设置一个合理的
资源未关闭（连接、结果集、流）
这是导致内存泄漏和资源耗尽的“头号杀手”之一。在JSP或Servlet中直接操作数据库连接（Connection）、语句（Statement）、结果集（ResultSet）或者各种输入输出流（InputStream/OutputStream）时，务必确保它们在finally块中被关闭，或者直接使用Ja va 7引入的try-with-resources语法。一个更根本的建议是：尽量避免在JSP中直接编写数据库访问逻辑，把这些操作都封装到后端的DAO或Service层，从架构上降低泄漏风险。
静态集合与缓存泄漏
全局的static Map或List，以及自实现的缓存，如果没有设计合理的容量上限和过期淘汰策略，就会变成只进不出的“内存黑洞”。解决方案是使用更专业的缓存组件，比如Gua va Cache，并配置LRU等淘汰策略。如果非要自己管理，可以考虑使用WeakHashMap或软引用来辅助，并建立定期清理的机制。
ThreadLocal 使用不当
在使用线程池的场景下，这个问题尤其隐蔽。线程池中的线程是会复用的，如果使用了ThreadLocal却没有在任务处理完毕后调用remove()方法进行清理，那么ThreadLocal中存储的对象就会一直与该线程绑定，无法被垃圾回收。正确的做法是，在请求处理结束前务必清理，或者用try-finally块确保remove()方法一定会被执行。
Tomcat与JVM参数建议
一套合理的参数配置，是系统稳定运行的基石。这里有几个关键点值得注意：
- 堆与新生代：建议将初始堆大小
-Xms和最大堆大小-Xmx设置为相同的值，这样可以避免JVM在运行期间动态调整堆大小带来的性能抖动。通常，堆总大小不应超过可用物理内存的80%。新生代大小-Xmn可以设置为堆大小的1/4左右，例如：-Xms4g -Xmx4g -Xmn1g。 - 元空间（JDK 8+）：根据应用实际使用的类多少来设置
-XX:MetaspaceSize和-XX:MaxMetaspaceSize。设置太小会导致频繁的Full GC去扩容，设置太大又会浪费内存，需要找到一个平衡点。 - GC 日志与监控：再次强调，务必开启详细的GC日志（
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log），并配合jstat、jmap等工具进行持续观测，这是了解JVM内部状态的窗口。 - 容器与部署：从部署层面优化，减少不同Web应用间重复的JAR包加载，严格控制热部署的频率。如果可能，将公共的JAR包统一放到Tomcat的
shared/lib目录下。
快速排查清单
当问题发生时，可以按照这个清单快速过一遍，能帮你迅速定位方向：
- 观察GC行为：用
jstat -gc看看Full GC后老年代空间是否被有效回收；用jmap -dump配合MAT分析堆转储，重点看支配树和泄漏疑点；检查GC日志确认回收效率。 - 检查Session管理：确认页面是否真的需要会话（不需要则加
session=“false”）；检查web.xml中的session-timeout设置是否合理；审查代码，避免在Session中缓存过大的业务对象。 - 审查代码逻辑：仔细检查JSP和Ja va代码中，数据库连接、结果集、流等资源是否确保关闭；检查是否有
static修饰的集合或缓存无限增长；确认ThreadLocal是否在finally块中调用了remove()。 - 检查类加载：排查是否存在JAR包重复、频繁热部署的情况；公共JAR是否可以考虑统一放置；根据JDK版本检查非堆/元空间的内存配置是否合理。
