在Ubuntu环境下处理JSP应用的内存泄漏，与其等问题爆发后手忙脚乱，不如提前打好预防针。下面我们从几个关键维度一一拆解，每一步都紧扣实际运维场景，不讲空话。
1. 调整JVM内存参数，避免因内存不足导致泄漏加剧
JSP运行在Servlet容器（如Tomcat）中，JVM参数配置不当，内存泄漏就会像滚雪球一样越滚越大。核心思路是合理分配堆内存：通过-Xms设置初始堆、-Xmx设置最大堆，减少频繁GC带来的性能损耗。需要注意，Ja va 8及以上版本已经用-XX:MaxMetaspaceSize替代了老版的-XX:MaxPermSize（永久代）。同时，别忘了开启GC日志（-verbose:gc、-XX:PrintGCDetails）和堆转储（-XX:+HeapDumpOnOutOfMemoryError），这些是事后分析泄漏根源的“黑匣子”。
2. 使用内存分析工具定位泄漏根源
光靠猜可不行，得用工具说话。当怀疑内存泄漏时，先用jmap -dump:format=b,file=heapdump.hprof 生成堆转储文件，然后交给Eclipse Memory Analyzer (MAT)或VisualVM来分析。这些工具能清晰地展示对象引用链，快速揪出那些占用内存过多的“罪魁祸首”——比如未释放的集合、静态变量中残留的对象，甚至能定位到具体是哪个类、哪个方法在作祟。
3. 优化代码，消除常见泄漏场景
代码层面的“坑”最多，也是最容易反复踩的地方。几个典型场景值得反复检查：
- 及时关闭资源：数据库连接、文件流、网络连接……这些资源用完必须释放。Ja va 7+可以用
try-with-resources语句自动关闭，否则就老老实实写在finally块里，别偷懒。 - 避免静态集合滥用：静态
HashMap之类的集合生命周期跟应用一样长，如果里面塞了大量对象又不清理（比如缓存只进不出），这些对象永远别想被GC回收。建议改用WeakHashMap（弱引用）或者为缓存设置过期策略，比如LinkedHashMap的removeEldestEntry方法。 - 正确使用ThreadLocal：
ThreadLocal变量用完后如果不调用remove()，线程池复用时就会残留旧对象，造成内存泄漏。务必在每次使用完毕后清理。 - 减少长生命周期对象引用：单例、静态类这类长寿命对象里，尽量不要持有短生命周期对象的引用（比如请求参数、临时变量）。缩短对象的存活时间，GC才能及时回收。
4. 监控内存使用，及时发现异常
最好的防守是主动出击。用jstat -gc （每秒采样一次，共5次）监控JVM内存状态，重点关注Eden区、Survivor区、老年代的使用率以及GC次数（YGC、FGC）。如果老年代使用率持续攀升，且Full GC次数激增却回收不了多少内存，那基本可以判定内存泄漏了。此外，VisualVM或JConsole也能实时监控堆内存、线程、类加载情况，直观地看到内存变化趋势。
5. 处理特定场景的泄漏问题
有些泄漏藏得比较深，需要针对特定场景单独处理：
- Session对象泄漏：如果每个请求都创建新Session，或者
session-timeout设置得过长（比如一天），Session对象会越积越多。在web.xml中把session-timeout设为合理值（例如30分钟），或者对不需要Session的JSP页面用page指令禁用Session（session="false"）。 - 类加载器泄漏：自定义类加载器如果没被正确卸载（比如动态加载的类始终占用元空间），就会导致Metaspace内存泄漏。确保类加载器的生命周期与应用的模块保持一致，避免重复加载同一个类。
