什么是内存泄漏？你在项目中是怎么排查OOM问题的？常用的JVM调优参数你知道哪些？
1. 什么是内存泄漏？
内存泄漏指的是程序中已动态分配的堆内存，由于某种原因未能被释放或无法被释放，造成系统内存的浪费。
通俗比喻： 就像水龙头没关紧，水（内存）在不停地滴漏。虽然一滴水很少，但时间长了就会浪费大量水资源（最终导致内存耗尽）。
与内存溢出的关系： 内存泄漏是原因，内存溢出（OOM）是结果。持续的内存泄漏最终会导致内存溢出。
Java中的典型内存泄漏场景（即对象无法被GC回收的原因）：
静态集合类持有引用： 静态集合（如static HashMap）的生命周期与程序一致，如果向其中添加对象后忘记移除，这些对象就永远无法回收。
连接未关闭： 数据库连接、网络连接（Socket）、文件流等未显式关闭。这些连接对象不仅本身占内存，其背后可能还关联着大量资源。
监听器未注销： 在图形界面编程中，注册了事件监听器，但在对象不需要时没有注销，导致监听器一直持有对该对象的引用。
内部类持有外部类引用： 非静态内部类（包括匿名内部类）会隐式持有其外部类的引用。如果内部类的生命周期长于外部类（例如，将内部类实例传递给一个后台线程），就会导致外部类实例无法被回收。
变量作用域不合理： 将局部变量不必要地提升为成员变量或静态变量，延长了其生命周期。
缓存滥用： 使用无界缓存（如HashMap做缓存）且没有淘汰策略，缓存会无限增长。
2. 你在项目中是怎么排查OOM问题的？
这是一个考察实战经验的问题。回答时要体现出清晰的排查思路和熟练的工具使用。以下是一个标准的排查流程：
总体思路： 定位问题 -> 分析快照 -> 修复代码。
第一步：快速定位问题源
查看日志： 首先查看应用日志和GC日志，确认OOM是发生在堆内存（Java heap space）、元空间（Metaspace）还是直接内存（Direct buffer memory）。这是最关键的第一步，因为不同区域的OOM原因和排查工具不同。
添加JVM参数： 在启动脚本中添加以下参数，以便在OOM时自动生成堆转储文件（Heap Dump）。
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/save/dump.hprof
-XX:+PrintGCDetails
-Xloggc:/path/to/gc.log
第二步：使用工具分析Dump文件
当OOM发生时，JVM会自动在指定路径生成一个 .hprof文件。这是案发现场的“内存快照”
使用MAT（Memory Analyzer Tool）或JProfiler进行分析：
打开Dump文件： 将 .hprof文件导入MAT。
查看概览： MAT会生成一个报告，直接提示可疑的内存泄漏点，比如“Problem Suspect 1”会指 出 哪个对象占用了最多的内存。
分析支配树： 查看 Histogram（直方图），按对象类型（Class）或类加载器（ClassLoader）分组，看哪种对象实例数量最多、总大小最大。
查找GC Root： 对疑似泄漏的对象，使用 “Merge Shortest Paths to GC Roots”功能，排除弱引用等，查看是谁在引用这些对象，阻止了GC回收。这是找到内存泄漏根源的关键步骤。
第三步：代码修复与验证
根据MAT的分析结果，定位到代码中导致泄漏的地方（例如，未关闭的资源、静态集合未清理等），进行修复。修复后，在预发布环境进行压测，验证问题是否解决。
一个实战案例描述：
我们线上有一个服务曾发生Java heap space的OOM。我首先在启动参数中配置了-XX:+HeapDumpOnOutOfMemoryError。当OOM再次发生时，拿到了dump文件。用MAT打开后，发现有一个HashMap的实例占用了接近1GB内存。通过查看其GC Roots路径，发现它是一个静态的缓存类中的字段，但由于代码逻辑问题，缓存只增不减，没有设置过期或淘汰策略。我们的解决方案是，用一个有大小限制和LRU淘汰策略的Guava Cache替代了原来的HashMap，问题得以解决。”
3. 常用的JVM调优参数你知道哪些？
不要死记硬背所有参数，要分类记忆，并理解其用途。调优的首要原则是“不做优化”，除非有明确的性能指标（如GC停顿时间过长、吞吐量下降）表明需要调优。
A. 堆内存相关（最核心）
-Xms： 初始堆大小。例如 -Xms4g。
-Xmx： 最大堆大小。通常将 -Xms和 -Xmx设置为相同值，以避免堆内存动态调整带来的性能损耗。
-Xmn： 新生代大小（Eden + 2*Survivor）。官方建议是整个堆的 3/8 左右。增大新生代会减小老年代，需要根据对象生命周期来权衡。G1收集器不建议设置。
-XX:NewRatio： 老年代/新生代的比例。例如 -XX:NewRatio=2表示老年代是新生代的2倍。
-XX:SurvivorRatio： Eden区/Survivor区的比例。例如 -XX:SurvivorRatio=8表示Eden占新生代的8/10，每个Survivor占1/10。
B. 元空间相关
-XX:MetaspaceSize： 初始元空间大小。达到该值会触发Full GC进行类型卸载。
-XX:MaxMetaspaceSize： 最大元空间大小。默认无限制，但建议设置，防止过度使用本地内存。
C. GC日志相关（排查必备）
-XX:+PrintGCDetails： 打印详细的GC信息。
-Xloggc:<file>： 将GC日志输出到文件。例如 -Xloggc:/opt/logs/gc.log。
-XX:+PrintGCTimeStamps/ -XX:+PrintGCDateStamps： 在GC日志中增加时间戳，便于分析。
D. 垃圾收集器选择（根据JDK版本和需求）
JDK 8及之前：
-XX:+UseParallelGC： 新生代使用Parallel Scavenge。
-XX:+UseParallelOldGC： 老年代使用Parallel Old。
低延迟应用（JDK 8）：
-XX:+UseConcMarkSweepGC： 使用CMS收集器。
JDK 8+（尤其是大堆内存）：
-XX:+UseG1GC： 使用G1收集器。
超低延迟（JDK 11+）：
-XX:+UseZGC： 使用ZGC收集器（TB级堆内存，停顿时间不超过10ms）。
E. OOM相关
-XX:+HeapDumpOnOutOfMemoryError： 发生OOM时自动生成Dump文件。
-XX:HeapDumpPath=<path>： 指定Dump文件路径。
总结： 大部分业务系统使用默认的GC参数即可。常见的调优动作是设置合理的堆大小（-Xms, -Xmx）和开启GC日志。更深入的调优（如选择收集器、调整新生代大小等）需要结合监控工具（如Prometheus + Grafana）的指标进行分析。