JVM调优

38. Full GC 的触发条件？

回答：
Full GC 触发的场景主要包括老年代空间不足、空间分配担保失败、System.gc() 显式调用、以及旧版本 JVM 中永久代（PermGen）空间溢出等情况。

分析：
Full GC 是一种涉及整个堆（新生代+老年代）甚至方法区的全面垃圾回收过程，其代价通常较高，因此触发条件必须特别关注。常见触发机制包括：

老年代空间不足：当大对象直接分配至老年代，或者大量对象在新生代晋升失败，导致老年代可用空间不足时，会触发 Full GC。
空间分配担保失败：新生代使用复制算法回收时，需要老年代提供足够空间作为晋升担保。如果老年代无法提供担保，也将触发 Full GC。
System.gc() 调用：开发者显式调用 System.gc() 可能会引导 JVM 执行 Full GC，虽然 JVM 不一定立即响应，但建议避免在生产代码中使用。
JDK 1.7 及以前的永久代溢出：在旧版本中，方法区实现为永久代，若类元数据、常量池、静态变量加载过多，可能引发 PermGen 空间溢出，进而触发 Full GC，甚至 OOM。
合理配置堆参数（如 -Xmx、-Xmn、-XX:MaxTenuringThreshold）和选择合适 GC 策略，有助于减少 Full GC 的频率和影响。

39. 线上系统发生了 Full GC 应该怎么快速定位？

回答：
可以通过收集 GC 日志、使用内存监控工具、分析内存分布和对象存活情况，配合代码审查与参数调优，多维度定位 Full GC 发生的原因。

分析：
线上系统一旦频繁发生 Full GC，可能引发系统响应卡顿、吞吐下降等严重后果。定位思路可分为多个环节：

日志分析：确保启动参数中启用了 GC 日志（如 -Xlog:gc* 或 -XX:+PrintGCDetails），观察 GC 频率、停顿时间及回收效果。
监控工具：使用 VisualVM、JConsole、Arthas、JFR 等工具实时查看堆内存使用趋势，判断是否存在异常对象持续增长或内存回收不及时现象。
堆快照分析：在 Full GC 发生前后生成堆 Dump 文件，借助 MAT、JProfiler 工具查找内存占用最大的对象、静态引用链等，识别内存泄漏或缓存未清理问题。
代码排查：重点审查长生命周期对象的持有方式、集合未清理、缓存未过期、ThreadLocal 泄漏等高发问题点。
JVM 参数检查：必要时调整堆大小、新生代比例、GC 策略，或设置适当的内存阈值避免误触发 Full GC。
通过这些手段，可较快定位问题根源，减少线上风险。

40. 怎么解决频繁 Full GC？

回答：
解决 Full GC 频繁问题需从内存结构配置、代码设计、对象生命周期控制以及垃圾回收器选择等多个维度综合优化。

分析：
频繁 Full GC 往往意味着老年代空间紧张或对象未能及时回收。优化策略如下：

调整堆配置：通过合理设置 -Xmx 增加堆总量，-Xmn 控制新生代大小，从而减少对象频繁晋升老年代。
优化对象使用：减少临时对象创建，尤其是在高频方法或循环中，避免缓存对象持续增长不被释放。
引用管理优化：使用 WeakReference 或 SoftReference 替代强引用缓存，避免无效引用导致对象常驻内存；及时将无用对象置为 null。
内存泄漏排查：定期检查集合类是否存在未清理元素，或是否存在 ThreadLocal 造成的隐式引用。
GC 策略选择：根据系统对吞吐量或延迟的敏感度，选择 G1、ZGC、CMS 等合适回收器，替代可能存在停顿问题的默认 GC。
模拟测试环境还原问题：在预发布或测试环境中复现 Full GC 场景，有助于精准验证调优效果。
Full GC 本质上是 JVM 的"自保行为"，一旦频繁出现，多数意味着内存压力已临近瓶颈，必须系统性优化处理。

41. JVM 常见参数有哪些？

回答：
JVM 参数用于控制内存配置、GC 行为与调试信息输出，常见参数包括堆内存设置、元空间大小、线程栈大小、GC 策略等。

分析：
JVM 参数分为多种用途，合理设置可显著提升应用性能。以下是典型参数分类：

堆内存配置：
- -Xms<size>：初始堆大小；
- -Xmx<size>：最大堆大小。建议两者相同以避免运行期频繁扩容。
元空间（Java 8 以后）或永久代（Java 7 及以前）配置：
- -XX:MetaspaceSize、-XX:MaxMetaspaceSize 控制元空间大小；
- -XX:PermSize、-XX:MaxPermSize 控制永久代容量（Java 7 前）。
线程栈大小：
- -Xss<size>：设置每个线程的栈空间，默认 1MB，线程多时需适当下调。
垃圾回收器指定：
- -XX:+UseG1GC：G1 收集器；
- -XX:+UseParallelGC：吞吐量优先；
- -XX:+UseConcMarkSweepGC：CMS 并发低停顿（已废弃）。
调试与日志：
- -XX:+PrintGCDetails 打印 GC 详细信息；
- -Xlog:gc*（JDK9+）统一日志机制；
- -XX:+HeapDumpOnOutOfMemoryError 在 OOM 时导出堆快照。
  通过灵活组合这些参数，可为不同类型的 Java 应用提供良好的内存与性能保障。

42. JVM 调优常用命令有哪些？

回答：
常用命令包括 jps、jstack、jstat、jmap，用于定位内存问题、线程死锁和 GC 行为。

分析：
在 JVM 调优与排障过程中，命令行工具极其重要：

jps：查看所有 Java 进程 ID（PID），可加 -lvm 查看主类、JVM 参数等详情；
jstack：输出指定 PID 的线程堆栈，使用 jstack -l pid 可查看锁信息，适合排查死锁、阻塞；
jstat：监控 JVM 内存与 GC 状态，如 jstat -gcutil pid 显示各代内存使用率、GC 次数与耗时；
jmap：导出或分析堆内存快照，命令如 jmap -dump:format=b,file=dump.hprof pid，也可用 -heap 查看堆配置信息；
这些命令常结合使用：如先用 jps 获取进程，再 jstack 排查死锁、jstat 看 GC 压力，必要时用 jmap 拿堆快照交由 MAT 分析。掌握这些工具是 JVM 故障排查的基础。

43. 如何排查 OOM 的问题？

回答：
排查 OOM 可从日志入手，结合 HeapDump 文件分析内存占用，识别内存泄漏或对象堆积的根源。

分析：
OOM（OutOfMemoryError）发生时，首要任务是捕获现场：

启用堆转储：添加参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path，自动保存发生 OOM 时的内存快照；
GC 日志辅助判断：搭配 -XX:+PrintGCDetails、-Xlog:gc* 等参数，查看回收频率与堆使用变化，初步判断泄漏方向；
使用分析工具：用 Eclipse MAT、JProfiler 加载 .hprof 文件，识别大对象、引用链、静态持有者等异常点；
明确 OOM 类型：如是 Java heap space、Metaspace、GC overhead limit exceeded 等，处理策略各异；
代码审查：排查长生命周期对象、未释放集合、无限缓存、线程泄漏等潜在内存风险点。
排查 OOM 关键在于及时捕获和对 Dump 的高效分析，结合实际业务定位根因，及时修复内存异常。

44. 如何诊断 Java 线程死锁（使用 jstack）？

回答：
通过 jstack 查看线程堆栈，分析线程状态和锁依赖关系，识别是否存在循环等待，从而判断是否发生死锁。

分析：
线程死锁是多个线程因竞争资源相互等待，形成循环依赖，导致系统卡顿甚至停滞。诊断步骤如下：

获取进程 ID：使用 jps 或 ps -ef | grep java 确定目标 JVM 进程；
导出线程快照：执行 jstack -l pid > dump.txt 获取当前所有线程堆栈及锁信息；
分析堆栈：查找 BLOCKED 和 WAITING 状态的线程，注意其等待的锁对象与被持有者之间的引用关系；
定位循环依赖：若线程 A 持有锁 X 等待锁 Y，线程 B 持有锁 Y 等待锁 X，即可判定为死锁；
辅助工具：VisualVM、JConsole 等 GUI 工具也可图形化展示线程锁依赖。
解决死锁需保证加锁顺序一致，或使用可中断锁（如 tryLock）避免无限等待，是并发编程中的基础防御技能。