Java内存模型（jmm）确保多线程环境下的可见性、有序性和原子性，通过volatile、synchronized等机制保障线程间变量的正确交互；gc机制则自动管理内存，采用标记-清除、复制、整理等算法及分代收集策略回收无用对象，提升内存利用率。1.jmm通过happens-before原则定义操作顺序，确保共享变量的可见性，避免缓存不一致和指令重排带来的并发问题；2.gc机制根据应用对吞吐量或延迟的需求选择合适收集器，如parallel追求高吞吐，cms、g1、zgc等适用于低延迟场景；3.排查oom需分析堆转储文件、监控metaspace使用、检查线程创建限制，并结合日志与工具定位内存泄漏根源。
说起Java应用，稳定性和性能总是绕不开的话题。这背后，Java内存模型（JMM）和垃圾回收（GC）机制扮演着决定性的角色。它们不是简单的概念，而是深入理解Java并发和内存管理的关键。简单来说，JMM定义了Java程序中各种变量的访问规则，确保了多线程环境下的可见性、有序性和原子性；而GC机制则负责自动管理内存，避免了传统C/c++中手动内存管理带来的诸多麻烦和内存泄漏问题。理解它们，是写出高性能、高并发、无内存泄露的Java代码的基石。
Java内存模型（JMM）和GC机制是构建健壮Java应用不可或缺的基石。JMM，在我看来，它更像是一套“契约”，明确了线程如何与主内存交互，以及不同线程之间对共享变量的可见性规则。这套契约避免了处理器缓存优化和指令重排序可能带来的并发问题。它通过volatile、synchronized、final关键字以及Happens-Before原则来保障可见性、有序性和原子性。比如，volatile关键字就保证了变量修改的立即写入主内存，并强制其他线程从主内存读取最新值，防止了缓存不一致。而synchronized不仅提供互斥，还隐含了内存语义，确保了进入同步块前的所有写操作对后续进入该同步块的线程可见。
GC机制则完全是另一回事，它解放了我们对内存的关注。jvm会周期性地识别并回收那些不再被引用的对象所占据的内存空间。这背后涉及复杂的算法，从最基础的引用计数（Java未使用）到可达性分析，再到各种分代收集器（新生代、老年代），以及针对不同场景优化的GC算法，如标记-清除、标记-复制、标记-整理。新生代通常采用复制算法，因为对象生命周期短，复制成本低；老年代则更倾向于标记-整理或标记-清除，以减少内存碎片。不同的GC收集器，如Serial、Parallel、CMS、G1、ZGC、Shenandoah，各有侧重，有的追求吞吐量，有的追求低延迟，选择不当，可能会让你的应用性能大打折扣。
立即学习“Java免费学习笔记（深入）”；
为什么多线程环境下，变量的可见性如此重要？
在多线程编程中，变量的可见性问题是导致许多难以察觉bug的根源。我个人觉得，很多开发者在遇到并发问题时，往往直觉性地想到锁，却忽略了更底层的JMM。这就像盖房子，地基不稳，上面怎么加固都白搭。问题的核心在于，每个线程都有自己的工作内存（可以理解为CPU缓存），它会把主内存中的共享变量拷贝一份到自己的工作内存中进行操作。当一个线程修改了变量，这个修改可能只反映在它的工作内存中，而没有立即同步到主内存，更不会立即同步到其他线程的工作内存。结果就是，其他线程可能读取到的是一个过期的、脏的数据。
举个例子，一个简单的Boolean flag = false;，在一个线程里将其设置为true，另一个线程循环检测flag。如果没有适当的内存屏障或同步机制，即便第一个线程将flag改成了true，第二个线程也可能永远看不到这个变化，因为它一直从自己的旧缓存中读取false。这就是典型的可见性问题。JMM通过Happens-Before原则，明确规定了哪些操作是可见的。比如，对volatile变量的写操作，Happens-Before于后续对这个volatile变量的读操作。这意味着，写volatile变量会强制刷新到主内存，读volatile变量会强制从主内存读取最新值，从而保证了可见性。理解这一点，对于避免并发陷阱，尤其重要。
如何选择合适的GC垃圾回收器来优化应用性能？
选择合适的GC垃圾回收器，确实是Java性能调优里一个非常关键，也常常让人头疼的问题。这没有一劳永逸的答案，很大程度上取决于你的应用场景、硬件资源以及对延迟和吞吐量的具体要求。在我看来，这更像是一种权衡和妥协的艺术。
- 追求高吞吐量（Throughput）的应用： 如果你的应用是批处理、数据分析这类，可以容忍偶尔的长时间GC停顿（STW），那么Parallel Scavenge（新生代）和Parallel Old（老年代）组合可能是个不错的选择。它们是JDK 8默认的GC，充分利用多核CPU来加速垃圾回收，但代价是GC期间应用会完全停止响应。
- 追求低延迟（Low Latency）的应用： 对于Web服务、实时交易系统这类对响应时间非常敏感的应用，你需要尽量减少GC停顿。
- CMS（Concurrent Mark Sweep）： 曾经的低延迟GC代表，它的大部分工作与应用线程并发执行，减少了STW时间。但它有碎片问题，并且在并发阶段可能会消耗CPU资源，且在GC失败时会退化为Serial Old，导致长时间停顿。JDK 9已被标记为废弃，JDK 14移除。
- G1（Garbage First）： JDK 9及之后版本默认的GC。它将堆划分为多个区域（Region），可以预测GC停顿时间。G1在吞吐量和低延迟之间做了很好的平衡，适合堆内存较大的应用（GB级别），并且可以有效地处理内存碎片。它通过Region的局部回收，避免了全堆扫描。
- ZGC和Shenandoah： 这是最新的低延迟GC，目标是将GC停顿时间控制在10毫秒以内，甚至更短，与堆大小无关。它们都是基于Region的并发收集器，并且都支持并发的引用更新。ZGC是JDK 11引入，Shenandoah是JDK 12引入。如果你的应用对延迟要求极高，且硬件配置允许（它们通常需要更多的CPU和内存资源），那么它们是未来的趋势。
我的建议是，先用默认的G1跑起来，然后通过GC日志分析、JConsole、VisualVM、JFR等工具观察GC行为。如果发现GC停顿时间过长，或者频繁发生，再根据具体问题（是新生代回收慢还是老年代回收慢，是内存碎片还是对象分配过快）去尝试调整GC参数或切换GC收集器。没有最好的GC，只有最适合你应用的GC。
JVM内存溢出（OOM）常见原因与排查策略有哪些？
JVM内存溢出（OutOfMemoryError，简称OOM）是Java应用中非常常见且让人头疼的运行时错误。它意味着JVM没有足够的内存来分配给新的对象，或者无法完成某些操作。这事儿一旦发生，轻则服务响应变慢，重则直接崩溃。排查起来，有时候确实像大海捞针，但掌握一些基本套路，能大大提高效率。
常见OOM类型及原因：
-
java.lang.OutOfMemoryError: Java heap space：这是最常见的OOM。
- 原因： 堆内存不足。可能是代码中创建了大量对象，且这些对象长时间不被回收（存在引用），或者分配了过大的数组、集合。例如，一次性从数据库查询出千万条记录，全部加载到内存中。
- 排查：
-
java.lang.OutOfMemoryError: Metaspace：
- 原因： JDK 8及以后版本，PermGen被Metaspace取代。Metaspace存储类的元数据，默认情况下只受限于可用物理内存。但如果加载了大量的类（比如动态生成类、大量使用反射、热部署等），或者使用了一些老旧的框架，可能导致Metaspace耗尽。
- 排查：
- 监控类加载数量： 使用jstat -gcutil
观察MC（Metaspace容量）和MU（Metaspace使用量）。 - 调整JVM参数： -XX:MaxMetaspaceSize可以设置Metaspace的最大值。
- 检查代码： 是否有不规范的类加载，或者动态生成类的机制存在内存泄漏。
- 监控类加载数量： 使用jstat -gcutil
-
java.lang.OutOfMemoryError: unable to create new native Thread：
-
java.lang.OutOfMemoryError: GC overhead limit exceeded：
- 原因： JVM在进行大量GC，但回收的效果非常差，几乎没有可用内存。JVM为了避免应用程序长时间停顿在GC上，会抛出这个错误。默认情况下，如果GC时间占用了98%以上的时间，并且回收的堆空间小于2%，就会触发。
- 排查： 这通常是堆内存泄漏或内存不足的间接表现。需要回到前面分析堆内存泄漏的思路。
通用排查策略：
- 日志分析： 仔细检查应用日志和GC日志，OOM发生前通常会有一些异常或警告。
- JVM监控工具： jvisualvm、jconsole、Arthas、JProfiler等工具能实时监控JVM内存使用、GC情况、线程状态，帮助你快速发现问题。
- 代码审查： 针对性地审查可能导致内存泄漏的代码，如静态集合、缓存、未关闭的资源（数据库连接、文件流）、监听器未移除等。
记住，OOM通常是症状，而不是病因。关键在于找到导致内存消耗过大的根本原因。
