JVM 作为 Java 程序运行的核心环境，其内存管理、类加载机制及垃圾回收策略直接影响系统性能。文章深入剖析了 JVM 发展史、运行时数据区结构（堆、栈、方法区）、双亲委派模型及其破坏案例（JDBC）。重点讲解了对象存活判定算法（可达性分析 vs 引用计数）、主流垃圾回收算法（标记清除、复制、整理）及收集器（Serial、CMS、G1）。同时涵盖 JMM 内存模型与并发安全实践，如 DCL 单例模式中的 volatile 应用，为开发者提供从理论到实战的 JVM 调优参考。
JVM（Java Virtual Machine）即 Java 虚拟机。它通过软件模拟出一套具有完整硬件功能、运行在隔离环境中的计算机系统。
JVM 与通用虚拟机的区别：
了解发展史能让你明白技术演进的逻辑：
JVM 的运行可以概括为以下步骤：
.java 源码被编译为 .class 字节码。
这是 JVM 最核心的知识点，理解了这里，你才能读懂 Dump 文件。
作用：存放程序中创建的所有对象实例。
参数控制：-Xms (初始堆)、-Xmx (最大堆)。
结构划分：
java.lang.OutOfMemoryError: Java heap space。需检查内存泄漏或调大 -Xmx。StackOverflowError。
类加载包含以下 5 个关键步骤：
java.lang.Class 对象。int 为 0）。<clinit> 方法）。双亲委派模型的优点
在 JDBC 中，接口 Driver 在 rt.jar（Bootstrap 加载），但实现类在各个厂商的 Jar 包中（如 MySQL，需 App 加载）。此时 Bootstrap 加载器无法'下探'去加载 App 层级的类。
我们先来看下 JDBC 的核心使用代码：
public class JdbcTest {
public static void main(String[] args) {
Connection connection = null;
try {
connection = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306");
} catch (SQLException e) {
e.printStackTrace();
}
System.out.println(connection.getClass().getClassLoader());
System.out.println(Thread.currentThread().getContextClassLoader());
System.out.println(Connection.class.getClassLoader());
}
}
解决方案：引入 Thread Context ClassLoader (线程上下文加载器)，在 DriverManager 中实现逆向调用，从而打破双亲委派。
我们进入 DriverManager 的源码类就会发现它是存在系统的 rt.jar 中的，如下图所示：
由双亲委派模型的加载流程可知 rt.jar 是有顶级父类 BootstrapClassLoader 加载的，如下图所示：
而当我们进入它的 getConnection 源码是却发现，它在调用具体的类实现时，使用的是子类加载器（线程上下文加载器 Thread.currentThread().getContextClassLoader）来加载具体的数据库包（如 mysql 的 jar 包），源码如下：
@CallerSensitive
public static Connection getConnection(String url, java.util.Properties info) throws SQLException {
return (getConnection(url, info, Reflection.getCallerClass()));
}
private static Connection getConnection(String url, java.util.Properties info, Class<?> caller) throws SQLException {
ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
synchronized (DriverManager.class) {
// synchronize loading of the correct classloader.
if (callerCL == null) {
// 获取线程上下文为类加载器
callerCL = Thread.currentThread().getContextClassLoader();
}
}
if (url == null) {
throw new SQLException("The url cannot be null", "08001");
}
println("DriverManager.getConnection(\"" + url + "\")");
SQLException reason = null;
for (DriverInfo aDriver : registeredDrivers) {
// isDriverAllowed 对于 mysql 连接 jar 进行加载
if (isDriverAllowed(aDriver.driver, callerCL)) {
try {
println(" trying " + aDriver.driver.getClass().getName());
Connection con = aDriver.driver.connect(url, info);
(con != ) {
println( + con);
(con);
}
} (SQLException ex) {
(reason == ) {
reason = ex;
}
}
} {
println( + aDriver.getClass().getName());
}
}
(reason != ) {
println( + reason);
reason;
}
println( + url);
( + url, );
}
这样一来就破坏了双亲委派模型，因为 DriverManager 位于 rt.jar 包，由 BootStrap 类加载器加载，而其 Driver 接口的实现类是位于服务商提供的 Jar 包中，是由子类加载器（线程上下文加载器 Thread.currentThread().getContextClassLoader）来加载的，这样就破坏了双亲委派模型了（双亲委派模型讲的是所有类都应该交给父类来加载，但 JDBC 显然并不能这样实现）。它的交互流程图如下所示：
引⽤计数描述的算法为: 给对象增加一个引用计数器，每当有一个地方引用它时，计数器就 +1；当引用失效时，计数器就 -1； 任何时刻计数器为 0 的对象就是不能再被使用的，即对象已"死"。 引用计数法实现简单，判定效率也比较高，在大部分情况下都是一个不错的算法。比如 Python 语言就 采用引用计数法进行内存管理。 但是，在主流的 JVM 中没有选用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题
范例：观察循环引用问题
/**
* JVM 参数 :-XX:+PrintGC
* @author 38134
*/
public class Test {
public Object instance = null;
private static int _1MB = 1024 * 1024;
private byte[] bigSize = new byte[2 * _1MB];
public static void testGC() {
Test test1 = new Test();
Test test2 = new Test();
test1.instance = test2;
test2.instance = test1;
test1 = null;
test2 = null;
// 强制 jvm 进行垃圾回收
System.gc();
}
public static void main(String[] args) {
testGC();
}
}
[GC (System.gc())6092K->856K(125952K),0.0007504 secs]
从结果可以看出，GC 日志包含"6092K->856K(125952K)"，意味着虚拟机并没有因为这两个对象互相引用就不回收他们。即 JVM 并不使用引用计数法来判断对象是否存活。
在上面我们讲了，Java 并不采用引用计数法来判断对象是否已"死"，而采用"可达性分析"来判断对象是否存活 (同样采用此法的还有 C#、Lisp-最早的一门采用动态内存分配的语⾔)。
此算法的核心思想为：通过一系列称为"GCRoots"的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为"引用链"，当一个对象到 GCRoots 没有任何的引用链相连时 (从 GCRoots 到这个对象不可达) 时，证明此对象是不可用的。以下图为例：
对象 Object5-Object7 之间虽然彼此还有关联，但是它们到 GC Roots 是不可达的，因此他们会被判定为可回收对象。
在 Java 语言中，可作为 GC Roots 的对象包含下面几种:
从上面我们可以看出'引用'的功能，除了最早我们使用它（引用）来查找对象，现在我们还可以使用'引用'来判断死亡对象了。所以在 JDK1.2 时，Java 对引用的概念做了扩充，将引用分为强引用 (Strong Reference)、软引用 (Soft Reference)、弱引用 (Weak Reference) 和虚引用 (Phantom Reference) 四种，这四种引用的强度依次递减。
"Object obj = new Object()"这类的引用，只要强引用还存在，垃圾回收器永远不会回收被引用的对象实例。JMM（Java Memory Model）规范了主内存与线程工作内存的交互。它主要解决三大问题：可见性、原子性、有序性。
源码复现：
public class Singleton {
private static volatile Singleton instance; // 必须加 volatile
public static Singleton getSingleton() {
if (instance == null) {
// 第一次检查
synchronized (Singleton.class) {
if (instance == null) {
// 第二次检查
instance = new Singleton();
}
}
}
return instance;
}
}
深度揭秘：new Singleton() 并非原子操作。如果不加 volatile，由于指令重排序，线程可能会获取到一个未完成构造的对象。volatile 的加入能保证可见性并禁止重排序。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online