Java 虚拟机是一个可以执行 Java 字节码的虚拟机进程。
 Java 源文件被编译成能被 Java 虚拟机执行的字节码文件，Java 被设计成允许应用程序可以运行在任意的平台，而不需要程序员为每一个平台单独重写或者是重新编译。Java 虚拟机让这个变为可能，因为它知道底层硬件平台的指令长度和其他特性。

 你可以检查某些系统属性如 sun.arch.data.model 或 os.arch 来获取该信息。

 理论上说上 32 位的 JVM 堆内存可以到达 2^32， 即 4GB，但实际上会比这个小很多。不同操作系统之间不同，如 Windows 系统大约 1.5GB，Solaris 大约3GB。64 位 JVM 允许指定最大的堆内存，理论上可以达到 2^64，这是一个非常大的数字，实际上你可以指定堆内存大小到 100GB。甚至有的 JVM，如 Azul，堆内存到 1000G 都是可能的。

 Java 直接内存（Direct Memory）是 JVM 堆外的内存区域，由操作系统直接分配和管理，不属于 JVM 运行时数据区的一部分。
 详见 直接内存

 一般都是在老年代，具体如下。

 方法区（Method Area）是 JVM 内存模型的一部分（Java 8 之前），用于存储类的元数据、常量、静态变量、方法字节码等。方法区本身不直接执行方法，而是为方法的执行提供必要的元数据支持。方法的真正执行发生在 虚拟机栈（JVM Stack） 和 执行引擎 中。以下是方法从加载到执行的完整流程：

1. 类加载阶段

• 加载（Loading）

  • 类加载器（ClassLoader）将类的字节码文件（.class）加载到方法区。
  • 方法区存储类的元信息：
    • 方法的字节码（Code 属性）
    • 方法签名（参数类型、返回值类型）
    • 访问修饰符（public/static 等）
    • 常量池（Constant Pool，包含字面量和符号引用）

• 链接（Linking）

  • 验证（Verification）：确保字节码符合 JVM 规范。
  • 准备（Preparation）：为静态变量分配内存并赋默认值（如 int 初始化为 0）。
  • 解析（Resolution）：将符号引用转换为直接引用（例如方法名的内存地址）。

• 初始化（Initialization）

  • 执行静态代码块（static{}）和静态变量的显式赋值。
  • 此时方法区中的方法字节码已准备好，但尚未执行。

2. 方法调用阶段
 当调用一个方法时（如 obj.method()）：

1. 解析方法符号引用

   • JVM 根据方法名和描述符，在方法区的常量池中查找方法的字节码地址。

2. 创建栈帧（Stack Frame）

   • 在虚拟机栈中为当前方法分配一个栈帧，包含：
     • 局部变量表：存储方法参数和局部变量。
     • 操作数栈：执行字节码指令的临时数据存储区。
     • 动态链接：指向方法区中该方法的符号引用。
     • 返回地址：方法执行完毕后返回的位置。

3. 执行字节码指令

   • 解释执行：解释器逐条读取方法区中的字节码，翻译为机器码执行。
   • 即时编译（JIT）：热点代码（频繁执行的方法）会被 JIT 编译器编译为本地机器码，直接由 CPU 执行。

3. 方法执行中的关键依赖

• 动态链接（Dynamic Linking）
  方法区中的常量池存储方法的符号引用（如 invokevirtual 指令），在运行时通过动态链接解析为实际的方法地址。

• 静态变量与常量
  静态变量（static）和类常量（final static）存储在方法区，方法执行时可直接访问。

• 异常表（Exception Table）
  方法区的字节码中包含异常表，记录 try-catch 块的范围和异常处理代码地址。

4. 方法执行结束

• 正常返回

  • 执行引擎将操作数栈顶的值作为返回值，返回到调用者的栈帧。
  • 虚拟机栈弹出当前栈帧，继续执行后续代码。

• 异常返回

  • 若发生未捕获的异常，虚拟机会查找异常表，跳转到对应的异常处理代码。
  • 若无处理逻辑，线程终止，栈帧被销毁。

5. 方法区与执行过程的关系总结

6. 关键区别

• 方法区：存储类的静态信息（方法字节码、常量、静态变量），是线程共享的内存区域。
• 虚拟机栈：存储方法调用的栈帧（局部变量、操作数栈），是线程私有的，直接支持方法执行。
• 执行引擎：负责解析和执行字节码，依赖方法区的元数据和栈帧的运行时状态。

7. 简而言之：方法区提供方法的“设计图纸”（元数据），虚拟机栈和执行引擎根据图纸“施工”（执行）。

 JVM 将内存划分为新生代、老年代和持久代（现为元空间），​​核心目的是基于对象生命周期的差异，采用分代垃圾回收策略以提升内存管理效率​​。具体作用如下：

• ​​新生代​​：存放生命周期极短的临时对象（如局部变量），采用复制算法快速回收（Minor GC），避免内存碎片。
• ​​老年代​​：存储长期存活对象（如缓存），使用标记-清除/整理算法（Full GC），减少高频回收的性能损耗。
• ​​持久代/元空间​​：管理类元数据、常量池等（Java 8 后由元空间替代，使用本地内存），与对象回收解耦以降低堆压力。

 这种分代设计通过 ​​差异化回收策略（高频小范围回收 vs 低频大范围回收）和​对象生命周期隔离​​，显著减少垃圾回收的停顿时间，并优化内存利用。

 Eden 区负责快速分配新对象（多数短命对象在此消亡），两个 Survivor 区通过交替复制存活对象（避免内存碎片）并筛选年龄达标者晋升老年代，从而降低 Full GC 频率。

• JVM 中堆空间可以分成三个大区，新生代、老年代、永久代。
• 新生代可以划分为三个区，Eden 区，两个幸存区。

 在 JVM 运行时，可以通过配置以下参数改变整个 JVM 堆的配置比例。

1. JVM 运行时堆的大小
-Xms 堆的最小值
-Xmx 堆空间的最大值
2. 新生代堆空间大小调整
-XX:NewSize 新生代的最小值
-XX:MaxNewSize 新生代的最大值
-XX:NewRatio 设置新生代与老年代在堆空间的大小
-XX:SurvivorRatio 新生代中 Eden 所占区域的大小
3. 永久代大小调整 -XX:MaxPermSize
4. 其他
-XX:MaxTenuringThreshold,设置将新生代对象转到老年代时需要经过多少次垃圾回收，但是仍然没有被回收

 对象的创建在虚拟机中是一个非常频繁的行为，哪怕只是修改一个指针所指向的位置，在并发情况下也是不安全的，可能出现正在给对象 A 分配内存，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案：

• 对分配内存空间的动作进行同步处理（采用 CAS + 失败重试来保障更新操作的原子性）；
• 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在 Java 堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer, TLAB）。哪个线程要分配内存，就在哪个线程的 TLAB 上分配。只有 TLAB 用完并分配新的 TLAB 时，才需要同步锁。通过 -XX:+/-UserTLAB1 参数来设定虚拟机是否使用 TLAB。

 Java 对象创建的核心流程为：​​类加载检查 → 内存分配 → 初始化零值 → 设置对象头 → 执行构造方法​​。内存分配策略和并发控制机制（如 TLAB(Thread-Local Allocation Buffer)）直接影响性能，而对象内存布局的设计优化了 GC 效率与访问速度。

 Java 对象的生命周期可概括为：​​创建阶段、应用阶段（被强引用持有）、不可达阶段（GC Roots 无法访问）、垃圾回收阶段（可能触发 finalize() 方法）及内存回收阶段。

• 启动类加载器：Bootstrap ClassLoader，用来加载 Java 核心类库，无法被 Java 程序直接引用，如加载存放在 JDK\jre\lib(JDK 代表 JDK 的安装目录，下同)下，或被 -Xbootclasspath 参数指定的路径中的，并且能被虚拟机识别的类库。
• 扩展类加载器：Extension ClassLoader，该加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载 JDK\jre\lib\ext 目录中，或者由 java.ext.dirs 系统变量指定的路径中的所有类库（如 javax.* 开头的类），开发者可以直接使用扩展类加载器。
• 应用程序类加载器：Application ClassLoader，该类加载器由 sun.misc.Launcher$AppClassLoader 来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器
• 用户自定义类加载器，通过继承 java.lang.ClassLoader 类的方式实现。

 双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，这样所有的加载请求都会被传送到顶层的启动类加载器中，只有当父加载无法完成加载请求（它的搜索范围中没找到所需的类）时，子加载器才会尝试去加载类。
 使用双亲委派模型的作用如下。

• 避免类的重复加载：通过父类加载器优先加载类，确保同一类在JVM中仅被加载一次，减少内存占用和版本冲突风险。
• 保证核心类库的安全性：防止用户自定义类覆盖JVM核心类（如java.lang.String），通过父类加载器优先加载核心类库实现安全隔离。
• 提高类加载效率：父类加载器已加载的类可直接复用，减少重复加载的开销。
• 隔离类加载器的命名空间：不同类加载器加载的类处于独立命名空间，避免类冲突（如Tomcat多Web应用场景）。
• 维护类的统一行为：确保核心类（如Object）在所有加载器中行为一致，避免因类版本不同导致的逻辑异常。

 类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、 初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中验证、准备、解析 3 个部分统称为连接（Linking）。
 详见 类加载过程。

 就是把类加载过程和双亲委派机制加载步骤说明下就行了。

 Java 垃圾回收（Garbage Collection, GC）是 JVM 提供的自动内存管理机制，用于回收程序中不再使用的对象所占用的内存空间。
 其核心目标是如下 3 点。

• 内存泄漏​​：防止因对象长期未被释放导致的内存耗尽（如未关闭的文件句柄或数据库连接）。
• ​手动管理复杂性​​：避免开发者手动分配/释放内存时可能出现的错误（如野指针、双重释放）。
• ​内存碎片化​​：通过特定策略减少内存碎片，提升内存分配效率。

 垃圾回收的触发条件如下。

1. 内存分配失败

   • Minor GC（新生代回收）：当 Eden 区满时触发，通过复制算法快速回收存活率低的对象。
   • Major GC（老年代回收）：老年代空间不足时触发，通常伴随 Full GC。

2. 显式调用

   • 通过 System.gc() 或 Runtime.getRuntime().gc() 建议 JVM 执行垃圾回收，但 JVM 可能忽略该请求。

3. 阈值触发
   a. 堆内存使用率：当堆内存使用超过预设阈值（如 70%）时触发 GC。
   b. 永久代/元空间满：Java 8 之前 PermGen 区满触发；Java 8+ Metaspace 区满触发。

4. 时间间隔

   • 部分 JVM 实现基于固定时间间隔（如每小时）触发 GC，无论内存使用情况。

5. 并发标记清除（CMS/G1）

   • 低延迟回收器（如 CMS、G1）可能在并发标记阶段因内存碎片等问题触发 Full GC。

1. 核心区别

2. Full GC 的触发场景
   • 老年代空间不足
     • 对象晋升或大对象直接分配至老年代失败（通过 -XX:PretenureSizeThreshold 控制大对象阈值）。
   • 显式调用 System.gc()
     • 开发者主动触发（需未禁用 -XX:+DisableExplicitGC）。
   • 元空间/永久代不足
     • 类/方法元数据加载过多（需合理设置 -XX:MaxMetaspaceSize）。
   • 晋升失败（Promotion Failure）
     • Survivor 区空间不足，且老年代无法提供担保空间。
   • CMS 并发模式失败
     • CMS 回收器无法及时回收足够空间，退化为 Serial Old 触发 Full GC。
   • 分配大对象失败
     • Eden 区无法分配大对象，且老年代空间不足。
   • 空间分配担保失败
     • 老年代连续空间 < 新生代存活对象总大小（未开启 HandlePromotionFailure 时触发）。
   • 堆转储或诊断操作
     • 使用 jmap -dump 等工具强制触发。

 Minor GC 和 Major GC：详见 分代收集理论。

 主要回收两部分内容：废弃的常量和不再使用的类型。
 见 回收方法区。

 以 CMS 收集器为例说明。
 分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是 2/3。
 新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1，它的执行流程如下：

• 把 Eden + From Survivor 存活的对象放入 To Survivor 区；
• 清空 Eden 和 From Survivor 分区；
• From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，To Survivor 变 From Survivor。

 每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。

1. GC 流程全解析

   • 标记阶段

     • 可达性分析：从 GC Roots（虚拟机栈局部变量、静态属性、常量等）出发标记存活对象。
     • 两次标记机制：首次标记不可达对象，二次筛选未覆盖 finalize() 或已执行过的方法的对象直接回收。

   • 垃圾回收

     • 新生代回收（Minor GC）
       • 触发条件：Eden 区空间不足时自动触发。
       • 执行步骤：
         • 存活对象从 Eden 和 Survivor From 区复制到 Survivor To 区（年龄 +1）。
         • 清空 Eden 和 Survivor From 区，交换 From/To 区角色。
         • Survivor 空间不足时，存活对象通过分配担保机制直接进入老年代。
     • 老年代回收（Full GC/Major GC）
       • 触发条件：老年代空间不足、大对象分配失败、显式调用 System.gc() 等。
       • 执行步骤：
         • 采用标记-整理算法清理老年代内存碎片。
         • 回收后仍内存不足则抛出 OutOfMemoryError。

   • 内存整理与分配

     • 碎片整理：将存活对象紧凑排列（复制或移动）确保连续内存空间。
     • 指针碰撞分配：直接分配连续内存，避免空闲链表管理开销。

2. 对象晋升到老年代的条件

   • 年龄阈值机制
     • 对象每经历一次 Minor GC 且存活，年龄 +1，达到阈值（默认 15）时晋升。
     • 调整参数：-XX:MaxTenuringThreshold。
   • 动态年龄判定
     • Survivor 区中相同年龄对象总大小 > Survivor 空间的 50% 时，年龄 ≥ 该值的对象直接晋升。
   • 大对象直存老年代
     • 对象大小超过 -XX:PretenureSizeThreshold 设定值（如 30MB）时直接分配至老年代。
   • Survivor 区空间不足
     • Minor GC 后存活对象无法全部放入 Survivor 区时提前晋升。
   • 分配担保策略
     • Minor GC 前检查老年代剩余空间：
       • 剩余空间 < 历次晋升对象的平均大小时触发 Full GC。
       • Full GC 后仍不足则部分存活对象强制晋升。

• 对于 GC 来说，当程序员创建对象时，GC 就开始监控这个对象的地址、大小以及使用情况。通常，GC 采用有向图的方式记录和管理堆(heap)中的所有对象。通过这种方式确定哪些对象是"可达的"，哪些对象是"不可达的"。当 GC 确定一些对象为"不可达"时，GC 就有责任回收这些内存空间。
• 可以。
• 程序员可以手动执行 System.gc()，通知 GC 运行，但是 Java 语言规范并不保证 GC 一定会执行。

 垃圾回收不会发生在永久代，如果永久代满了或者是超过了临界值，会触发完全垃圾回收(Full GC)。如果你仔细查看垃圾收集器的输出信息，就会发现永久代也是被回收的。这就是为什么正确的永久代大小对避免 Full GC 是非常重要的原因。
 注意下 Java8 中已经移除了永久代，新加了一个叫做元空间的 native 内存区。

• 新生代回收器：Serial、ParNew、Parallel Scavenge
• 老年代回收器：Serial Old、Parallel Old、CMS
• 整堆回收器：G1

 新生代垃圾回收器一般采用的是复制算法，复制算法的优点是效率高，缺点是内存利用率低；老年代回收器一般采用的是标记-整理的算法进行垃圾回收。

 类的生命周期是 Java 虚拟机（JVM）管理类从加载到卸载的全过程，共分为​​加载（Loading）→ 连接（Linking）→ 初始化（Initialization）→ 使用（Using）→ 卸载（Unloading）​​五个阶段。
 详见 类加载的过程

 类装载是 Java 虚拟机（JVM）将类的字节码文件（.class）加载到内存并转化为可执行代码的过程，其执行流程可概括为​​加载、链接、初始化​​三个阶段，其中​链接阶段​​进一步分为​验证、准备、解析​​ 三个子步。
 详见 类加载的过程

 类的加载是将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class 对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的 Class 对象，Class 对象封装了类在方法区内的数据结构，并且向 Java 程序员提供了访问方法区内的数据结构的接口。通常是创建一个字节数组读入 .class 文件，然后产生与所加载类对应的 Class 对象。
 加载完成后，Class 对象还不完整，所以此时的类还不可用。当类被加载后就进入连接阶段，这一阶段包括验证、准备（为静态变量分配内存并设置默认的初始值）和解析（将符号引用替换为直接引用）三个步骤。最后 JVM 对类进行初始化，包括：

• 如果类存在直接的父类并且这个类还没有被初始化，那么就先初始化父类。
• 如果类中存在初始化语句，就依次执行这些初始化语句。

 类加载器：通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到 Java 虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”。
 类加载器有如下类型。

• 启动类加载器（Bootstrap Class Loader）

  • 由 JVM 自身用 C/C++ 实现，不继承 java.lang.ClassLoader，无法在 Java 代码中直接访问。
  • 功能：加载核心 Java 类库（如 rt.jar、resources.jar），路径为 <JAVA_HOME>/jre/lib 或 -Xbootclasspath 指定的目录。

• 扩展类加载器（Extension Class Loader）

  • 由 sun.misc.Launcher$ExtClassLoader 实现，父加载器为启动类加载器。
  • 功能：加载扩展目录（<JAVA_HOME>/jre/lib/ext 或 java.ext.dirs 指定路径）中的 JAR 文件。

• 应用程序类加载器（Application Class Loader/System Class Loader）

  • 由 sun.misc.Launcher$AppClassLoader 实现，父加载器为扩展类加载器。
  • 功能：默认加载用户类路径（ClassPath）下的类，是程序中默认的类加载器。

• 自定义类加载器（User-Defined Class Loader）

  • 开发者继承 ClassLoader 类实现，需重写 findClass() 方法。
  • 用途：动态加载网络资源、加密字节码、模块化隔离（如 Tomcat 热部署）等。

 详见 双亲委派模型。

 双亲委派模型​​是 Java 类加载器的层级委托机制，​​子加载器在加载类时会优先委派给父加载器处理，依次递归至最顶层的启动类加载器（Bootstrap ClassLoader），若父加载器无法加载，子加载器才会自行加载​​，以此保证核心类库的安全性（如防止用户篡改 java.lang.String）并避免重复加载。
 详见 双亲委派模型。

• Tomcat 类加载器为什么要破坏双亲委派机制？open in new window

• 首先利用 IDE 集成开发工具编写 Java 源代码，源文件的后缀为 .java；
• 再利用编译器(javac 命令)将源代码编译成字节码文件，字节码文件的后缀名为 .class；
• 运行字节码的工作是由解释器(java 命令)来完成的。

 从上图可以看，java 文件通过编译器变成了 .class 文件，接下来类加载器又将这些 .class 文件加载到 JVM 中。
 其实可以一句话来解释：类的加载指的是将类的 .class 文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class 对象，用来封装类在方法区内的数据结构。

 首先让我们看看 Java 中提供的几种对象创建方式：

 下面是对象创建的主要流程:

 虚拟机遇到一条 new 指令时，先检查常量池是否已经加载相应的类，如果没有，必须先执行相应的类加载。类加载通过后，接下来分配内存。若 Java 堆中内存是绝对规整的，使用“指针碰撞“方式分配内存；如果不是规整的，就从空闲列表中分配，叫做”空闲列表“方式。划分内存时还需要考虑一个问题-并发，也有两种方式: CAS 同步处理，或者本地线程分配缓冲(Thread Local Allocation Buffer, TLAB)。然后内存空间初始化操作，接着是做一些必要的对象设置(元信息、哈希码…)，最后执行 init 方法。

 Java 对象由三个部分组成：对象头、实例数据、对齐填充。
 对象头由两部分组成，第一部分存储对象自身的运行时数据：对象的哈希码、GC 分代年龄、锁标识状态、线程持有的锁、偏向线程 ID（一般占 32/64 bit）。第二部分是指针类型，指向对象的类元数据类型（即对象代表哪个类）。如果是数组对象，则对象头中还有一部分用来记录数组长度。
 实例数据用来存储对象真正的有效信息（包括父类继承下来的和自己定义的）。
 对齐填充：JVM 要求对象起始地址必须是 8 字节的整数倍（8 字节对齐）。

 摘录 GC 日志一部分（前部分为年轻代 gc 回收；后部分为 full gc 回收）：

2016-07-05T10:43:18.093+0800: 25.395: [GC [PSYoungGen: 274931K->10738K(274944K)] 371093K->147186K(450048K), 0.0668480 secs] [Times: user=0.17 sys=0.08, real=0.07 secs] 
2016-07-05T10:43:18.160+0800: 25.462: [Full GC [PSYoungGen: 10738K->0K(274944K)] [ParOldGen: 136447K->140379K(302592K)] 147186K->140379K(577536K) [PSPermGen: 85411K->85376K(171008K)], 0.6763541 secs] [Times: user=1.75 sys=0.02, real=0.68 secs]

 通过上面日志分析得出，PSYoungGen、ParOldGen、PSPermGen 属于 Parallel 收集器。其中 PSYoungGen 表示 gc 回收前后年轻代的内存变化；ParOldGen 表示 gc 回收前后老年代的内存变化；PSPermGen 表示 gc 回收前后永久区的内存变化。young gc 主要是针对年轻代进行内存回收比较频繁，耗时短；full gc 会对整个堆内存进行回城，耗时长，因此一般尽量减少 full gc 的次数。

• 1 基础故障处理工具
  • 1.1 jps: 虚拟机进程状态工具
  • 1.2 jstat: 虚拟机统计信息监视工具
  • 1.3 jinfo: Java 配置信息工具
  • 1.4 jmap: Java 内存映像工具
  • 1.5 jhat: 虚拟机堆转储快照分析工具
  • 1.6 jstack: Java 堆栈跟踪工具
  • 1.7 基础工具总结
• 2 可视化故障处理工具
  • 2.1 JHSDB: 基于服务性代理的调试工具
  • 2.2 JConsole: Java 监视与管理控制台
  • 2.3 VisualVM: 多合-故障处理工具
  • 2.4 Java Mission Control: 可持续在线的监控工具
• 3 HotSpot 虚拟机插件及工具

 见 虚拟机性能监控、故障处理工具。

1）堆栈配置相关

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:MaxPermSize=16m -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxTenuringThreshold=0
-Xmx3550m： 最大堆大小为 3550m。
-Xms3550m： 设置初始堆大小为 3550m。
-Xmn2g： 设置年轻代大小为 2g。
-Xss128k： 每个线程的堆栈大小为 128k。
-XX:MaxPermSize： 设置持久代大小为 16m
-XX:NewRatio=4: 设置年轻代（包括 Eden 和两个 Survivor 区）与年老代的比值（除去持久代）。
-XX:SurvivorRatio=4： 设置年轻代中 Eden 区与 Survivor 区的大小比值。设置为 4，则两个 Survivor 区与一个 Eden 区的比值为 2:4，一个 Survivor 区占整个年轻代的 1/6
-XX:MaxTenuringThreshold=0： 设置垃圾最大年龄。如果设置为 0 的话，则年轻代对象不经过 Survivor 区，直接进入年老代。

2）垃圾收集器相关

–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；
-XX:+UseParallelGC-XX:ParallelGCThreads=20-XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5-XX:+UseCMSCompactAtFullCollection：
-XX:+UseParallelGC： 选择垃圾收集器为并行收集器。
-XX:ParallelGCThreads=20： 配置并行收集器的线程数
-XX:+UseConcMarkSweepGC： 设置年老代为并发收集。
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次 GC 以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection： 打开对年老代的压缩。可能会影响性能，但是可以消除碎片

3）辅助信息相关

-XX:+PrintGC-XX:+PrintGCDetails
-XX:+PrintGC 输出形式:
[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails 输出形式:
[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs

1. 内存管理优化

   • 固定堆大小：-Xms 与 -Xmx 设为相同值（如 -Xms4g -Xmx4g）。
   • 年轻代占比 40%~50%：-XX:NewRatio=2，Survivor 区比例 -XX:SurvivorRatio=8。
   • 限制元空间：-XX:MaxMetaspaceSize=512m，大对象优先使用堆外内存（DirectByteBuffer）。

2. 垃圾回收器选型

   • G1：默认选择，平衡吞吐与延迟
     • 参数：-XX:+UseG1GC -XX:MaxGCPauseMillis=200
   • ZGC：超低延迟（TB 级堆）
     • 参数：-XX:+UseZGC -Xms16g -Xmx16g
   • Shenandoah：高并发内存压缩
     • 参数：-XX:+UseShenandoahGC

3. 线程与并发优化

   • 线程池大小：线程数 = CPU 核心数 * (1 + 平均等待时间/计算时间)。
   • 队列类型：使用有界队列（如 LinkedBlockingQueue）并设置拒绝策略。
   • 减少锁竞争：用 ReentrantLock 或 ThreadLocal 替代 synchronized。

4. 监控与诊断工具

   • 实时监控：jstat -gcutil <pid> 1000、Arthas（trace/watch 命令）。
   • 堆分析：jmap -dump:format=b,file=heap.hprof <pid> + MAT 工具。
   • GC 日志：-Xlog:gc*:file=gc.log，用 GCViewer 分析停顿原因。

5. 核心避坑指南

   • 避免动态堆扩容：固定 -Xms=-Xmx 防抖动。
   • 禁用 CMS：内存碎片问题，高并发场景不稳定。
   • 警惕无界队列：导致 OOM，需设置合理队列容量。

 比如原来一个程序，10 秒收集一次，停顿时间 100ms，通过调整参数，变为 5 秒收集一次，停顿时间 70ms。很明显吞吐量下来了，但响应速度上去了。  具体 JVM 猜应该是以老年代是并发还是并行为主的配置(待验证)，可参考理解。

• JVM 垃圾回收器（串行、吞吐量优先、响应时间优先、G1open in new window

• -XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。可以同时并行多个垃圾收集线程，但此时用户线程必须停止。
• -XX:+UseParNewGC:设置年轻代为多线程收集。可与 CMS 收集同时使用。在 serial 基础上实现的多线程收集器。

 JVM 中常量根据类型存储在不同区域：字符串字面量在堆的字符串常量池，类常量池在元空间，final 静态常量内联到代码，基本字面量嵌入字节码指令。

 结论如下。

• 代码运行位置：JVM 进程 → 操作系统 → CPU 物理核心。
• 线程运行位置：OS 线程 → CPU 逻辑核心（物理核心或超线程）。
• 核心依赖：JVM 是代码和线程的运行时容器，但最终依赖底层 CPU 资源。

 补充说明。

• Java 代码（.java文件）编译为 字节码（.class文件），字节码运行在 JVM（Java 虚拟机） 中。JVM 本身是一个 本地进程（如 java.exe 或 javaw.exe），其进程由操作系统调度到 CPU 物理核心 上运行。
• Java 线程本质是操作系统原生线程的封装。
  • 在大多数现代 JVM 实现（如 HotSpot）中，java.lang.Thread 实例直接映射到 操作系统线程（如 Linux 的 pthread、Windows 的线程 API）。
  • 线程调度由操作系统内核管理，具体运行在哪个 CPU 核心上由操作系统动态分配。

 Java 程序需要通过 JVM 栈上的引用访问堆中的具体对象。对象的访问方式取决于 JVM 虚拟机的实现。目前主流的访问方式有句柄和直接指针两种方式。

• 指针： 指向对象，代表一个对象在内存中的起始地址。
• 句柄： 可以理解为指向指针的指针，维护着对象的指针。句柄不直接指向对象，而是指向对象的指针（句柄不发生变化，指向固定内存地址），再由对象的指针指向对象的真实内存地址。

 直接指针。
 如果使用直接指针访问，引用中存储的直接就是对象地址，那么 Java 堆对象内部的布局中就必须考虑如何放置访问类型数据的相关信息。其优点如下。

• 速度更快，节省了一次指针定位的时间开销。由于对象的访问在 Java 中非常频繁，因此这类开销积少成多后也是非常可观的执行成本。HotSpot 中采用的就是这种方式。

 句柄访问。
 Java 堆中划分出一块内存来作为句柄池，引用中存储对象的句柄地址，而句柄中包含了对象实例数据与对象类型数据各自的具体地址信息，其优点如下。

• 引用中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而引用本身不需要修改。

 Java 中使用句柄的有如下场景。

• Java 通过 FileInputStream、FileOutputStream 等类操作文件时，底层会使用操作系统的文件句柄（File Handle）。如果未正确关闭资源（如调用 close()），可能导致句柄泄漏。
• 在调用本地代码（C/C++）时，JNI 通过句柄（如 jobject、jclass）间接引用 Java 对象，避免直接暴露内存地址。
   具体构造如下图所示。
  

 补充说明如下。

1. 直接内存（Direct Memory）：

   • 不属于 JVM 运行时数据区，但被 JVM 间接管理（如 NIO 的 ByteBuffer.allocateDirect）。
   • 回收依赖 Cleaner 机制（PhantomReference），Full GC 时可能触发，但建议手动调用 System.gc() 或显式释放（((DirectBuffer) buffer).cleaner().clean()）。

2. 其他特殊区域：

   • Code Cache：JIT 编译后的本地代码，由 JVM 单独管理，不依赖 GC。
   • 压缩类空间（Compressed Class Space）：在启用压缩指针时存储类元数据，属于 Metaspace 的一部分。

3. GC 不管理的区域：

   • 栈、程序计数器等线程私有区域，生命周期与线程绑定。
   • 直接内存需结合手动释放或 Cleaner 机制。

 垃圾回收算法中的标记阶段是实现内存管理的关键步骤，主要用于识别哪些对象是存活的，哪些是可以回收的。以下是几种常见的标记实现方式。

1. 标记-清除算法中的标记

 基本实现步骤：

• 从根对象（全局变量、栈变量等）开始遍历
• 对每个访问到的对象设置一个标记位（通常在对象头中）
• 递归或迭代地标记所有可达对象

2. 三色标记法

 更高效的标记方式，将对象分为三种颜色：

• 白色：未访问（初始状态）
• 灰色：已访问但引用的对象未完全处理
• 黑色：已访问且引用的对象已完全处理

 实现过程：

• 所有对象初始为白色
• 根对象标记为灰色并入队
• 从队列取出灰色对象，将其引用的白色对象标记为灰色
• 处理完所有引用后，该对象标记为黑色
• 重复直到灰色队列为空

3. 位图标记

 对于大规模堆内存的高效标记：

• 使用独立的位图来记录标记状态
• 每个位对应堆中的一个对象或内存块
• 减少对对象本身的修改，提高缓存效率

4. 写屏障与并发标记

 现代 GC（如 G1、ZGC）使用写屏障技术支持并发标记：

• 在对象引用修改时记录变化
• 维护标记的一致性
• 允许标记阶段与应用线程并发执行

 优化技术

• 并行标记：多线程同时进行标记
• 增量标记：将标记过程分成小步骤执行，减少停顿
• 卡表：记录堆中修改过的区域，缩小标记范围

 标记算法的选择取决于垃圾回收器的设计目标和应用程序的特性，注意以下一些说明。

• 卡表是位图的变种（粗粒度，记录内存区域而非单个对象）
• ZGC 的染色指针本质上是一种"无位图"设计，将标记信息嵌入指针
• Shenandoah 结合位图与 Brooks 指针实现并发移动

1 基本工作原理

 垃圾回收主要解决两个问题：

• 识别垃圾对象： 找出不再被程序使用的对象
• 回收内存空间： 释放这些对象占用的内存

2 垃圾识别算法

2.1 引用计数法

• 每个对象维护一个引用计数器
• 引用增加时计数器加 1， 减少时减 1
• 计数器为 0 时立即回收
• 缺点： 无法处理循环引用

2.2 可达性分析

• 从 GC Roots（栈、 静态变量等） 出发
• 遍历对象引用链
• 不可达的对象即为垃圾
• 主流 JVM 采用此方法

3 垃圾回收算法

3.1 标记-清除（Mark-Sweep）

• 标记阶段： 标记所有可达对象
• 清除阶段： 回收未标记对象
• 缺点： 产生内存碎片

3.2 标记-整理（Mark-Compact）

• 标记后， 将存活对象向一端移动
• 解决碎片问题但增加开销

3.3 复制算法（Copying）

• 将内存分为两块
• 只使用一块， 存活对象复制到另一块
• 优点： 无碎片， 简单高效
• 缺点： 内存利用率低

3.4 分代收集（Generational）

• 基于对象生命周期特点
• 新生代（Young Generation）： 频繁 GC， 使用复制算法
• 老年代（Old Generation）： 较少 GC， 使用标记-清除/整理

4 JVM 中的垃圾回收器

4.1 Serial GC

• 单线程， 简单高效
• 适合客户端应用

4.2 Parallel GC

• 多线程并行回收
• 注重吞吐量

4.3 CMS（Concurrent Mark-Sweep）

• 并发标记清除
• 减少停顿时间
• JDK9 后废弃

4.4 G1（Garbage-First）

• 分区收集， 可预测停顿
• JDK9+ 默认

4.5 ZGC

• 亚毫秒级停顿
• 支持 TB 级堆内存
• JDK15+ 生产可用

5 性能考量

5.1 衡量指标

• 吞吐量： GC 时间占总运行时间的比例
• 停顿时间： 单次 GC 暂停应用的时间
• 内存占用： GC 所需额外内存

5.2 调优方向

• 合理设置堆大小
• 选择适合场景的 GC 算法
• 调整新生代/老年代比例
• 监控 GC 日志分析瓶颈

6 发展趋势

• 向低延迟方向发展（ZGC, Shenandoah）
• 适应大内存和云原生环境
• 更智能的自适应调优

1. 循环引用导致内存泄漏

   • 对象间相互引用时，引用计数无法归零，即使失去外部引用也无法释放。

2. 性能开销

   • 频繁的引用增减操作需更新计数器，高频率场景下可能成为性能瓶颈。

3. 并发环境下的同步问题

   • 多线程修改引用计数需依赖锁或原子操作，增加竞争和性能损耗。

4. 内存释放的不确定性

   • 存在循环引用时，内存释放需等待引用关系解除，可能延迟到程序结束。

5. 无法处理复杂数据结构

   • 树、图等复杂结构易产生循环引用，需额外设计（如弱引用）避免泄漏。

6. 内存碎片化

   • 按需回收对象可能导致内存空间不连续，影响大块内存分配效率。

7. 对开发者透明性较低

   • 需手动管理部分引用（如弱引用），否则易引入内存泄漏问题。

 ​​GC Roots 是可达性分析的起点​​，它们是程序运行中始终活跃的引用。Java 体系中，固定可作为 GC Roots 的对象包括以下几种。

• 在虚拟机栈中（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
• 在方法区中类静态属性引用的对象，譬如 Java 类的引用类型静态变量。
• 在方法区中常量引用的对象，譬如字符串常量池里的引用。
• 在本地方法栈中 JNI(即 Native 方法) 引用的对象。
• Java 虚拟机内部的引用，如基本数据类型对应的 Class 对象，一些常驻的异常对象（比如 NullPointException、OutOfMemoryError）等，还有系统类加载器。
• 所有被同步锁（synchronized 关键字）持有的对象。
• 反映 Java 虚拟机内部情况的 JMXBean、JVMTI 中注册的回调、本地代码缓存等。

 除了这些固定的 GC Roots 集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整“GC Roots”集合。

 三色回收算法（Tri-color Marking）是一种高效的垃圾回收算法，核心思想是通过颜色标记跟踪对象存活状态，支持并发执行以减少停顿时间。以下是其核心内容整理：

 总结：三色标记法通过颜色划分和并发执行，在保证正确性的前提下显著降低GC停顿时间，是现代高性能垃圾回收器的核心算法。但其实现复杂度较高，需结合 SATB、增量更新等机制解决并发修改问题。

1. 核心目标

• 低停顿时间：专为减少老年代垃圾回收的 STW（Stop-The-World）时间设计，适用于对响应速度敏感的应用（如 Web 服务）。

2. 核心阶段
 CMS 基于标记-清除算法，分为四个阶段，其中两个阶段需 STW，两个阶段并发执行：

1. 初始标记（Initial Mark）

   • STW：短暂暂停应用线程，仅标记直接关联 GC Roots 的对象（如栈中局部变量引用的对象）。
   • 特点：耗时极短，通常与 Minor GC 配合触发。

2. 并发标记（Concurrent Mark）

   • 并发执行：与应用线程并行遍历对象图，递归标记所有可达对象。
   • 挑战：用户线程可能修改引用关系，导致漏标（需后续阶段修正）。

3. 重新标记（Remark）

   • STW：修正并发标记阶段的漏标对象。
   • 策略：
     • 增量更新（Incremental Update）：记录引用变化，重新处理被修改的引用链。
     • 原始快照（SATB, Snapshot-At-The-Beginning）：基于并发标记开始时的对象快照，确保漏标对象被扫描。

4. 并发清除（Concurrent Sweep）

   • 并发执行：回收不可达对象（白色对象），整理内存碎片。
   • 特点：与应用线程并发，但可能因内存碎片导致后续分配失败。

3. 关键实现机制

• 三色标记法：

  • 白色：未被访问的对象（待回收）。
  • 灰色：已访问但未完全扫描其引用的对象。
  • 黑色：已访问且所有引用均被扫描的对象（存活）。
  • 流程：从 GC Roots 出发，灰色对象逐步扩散至黑色，最终白色对象被回收。

• 并发与并行：

  • 并发：与用户线程同时运行（如并发标记、清除）。
  • 并行：多线程协同完成某一阶段（如初始标记和重新标记）。

• 内存碎片处理：

  • CMS 不压缩内存，长期运行可能导致碎片化，触发 Full GC（使用 Serial Old 收集器）。

4. 缺点与局限性

1. 浮动垃圾：并发标记期间产生的新垃圾无法立即回收，需等待下一轮 GC。
2. 内存碎片：标记-清除算法导致碎片，可能引发 Full GC（STW 时间较长）。
3. 并发模式失败：若并发阶段无法在限定时间内完成，会退化为Full GC。
4. CPU资源竞争：并发阶段占用 CPU 资源，可能影响应用吞吐量。

5. 适用场景

• 对延迟敏感：需快速响应用户请求（如电商交易系统）。
• 中小内存堆：适合堆内存较小（如几十 GB）且碎片问题可控的场景。
• JDK 8 及之前版本：JDK 9+ 中已被 G1 替代，但部分旧项目仍需维护。

6. 对比其他收集器

7. 总结

• 优势：通过并发执行显著降低停顿时间，适合对延迟敏感的应用。
• 劣势：内存碎片、并发失败风险及 CPU 资源消耗。
• 面试要点：
  • 明确阶段划分及 STW 环节。
  • 结合三色标记法解释漏标修正（SATB/增量更新）。
  • 对比 G1 的适用场景差异（碎片处理、分区设计）。

 详见 CMS 垃圾回收器。

1. 核心目标

• 平衡吞吐量与延迟：在保证高吞吐量的同时，尽可能减少停顿时间（通常控制在几百毫秒内），适用于大内存、多核 CPU 且对延迟敏感的应用（如在线事务处理系统）。

2. 核心设计

• 分代与分区结合：

  • 分代：保留年轻代（Young Generation）和老年代（Old Generation）的概念。
  • 分区：将整个堆划分为多个大小相等的 Region（默认 1~32MB，可通过-XX:G1HeapRegionSize调整），每个 Region 独立管理，可以是 Eden、Survivor、Old 或 Humongous（存储超大对象）。

• Humongous 区域：

  • 存储超过 Region 50% 大小的对象，连续分配在多个 Region 中，回收时优先处理。

3. 垃圾回收过程
 G1 的回收分为 Young GC 和 Mixed GC，均包含 STW 和 并发 阶段：

1. Young GC

   • 触发条件：Eden 区满时触发。
   • 流程：
     • STW 初始标记：标记 GC Roots 直接关联的对象。
     • 并发标记：遍历存活对象，记录引用关系。
     • 复制存活对象：将存活对象从 Eden/Survivor 区复制到新的 Survivor 区或老年代 Region。
   • 特点：年轻代 Region 回收后变为 Survivor 或老年代 Region。

2. Mixed GC

   • 触发条件：老年代占用达到阈值（默认 45%）时触发。
   • 流程：
     • 全局并发标记（与 Young GC 共享）：
       1. 初始标记（STW）：标记直接关联对象。
       2. 根区域扫描：扫描 Survivor 区的引用。
       3. 并发标记：遍历全堆，标记存活对象。
       4. 最终标记（STW）：处理并发阶段的引用变化（SATB 算法）。
       5. 筛选回收：根据 Region 的垃圾比例，选择回收价值高的 Region（优先回收年轻代 Region）。
     • 并发清理：回收选定 Region 的垃圾，整理内存。

4. 关键技术点

• Remembered Set（RSet）：

  • 每个 Region 维护一个 RSet，记录其他 Region 对该 Region 的引用（跨 Region 引用）。
  • 作用：避免全堆扫描，提升回收效率。例如，仅扫描 RSet 中记录的引用链。

• SATB（Snapshot-At-The-Beginning）算法：

  • 在并发标记开始时生成对象快照，确保标记过程中新增的引用关系被记录（通过写屏障实现）。
  • 用途：修正并发标记阶段的漏标对象。

• 混合回收策略：

  • 根据 Region 的垃圾占比（存活对象比例）动态选择回收目标，优先回收垃圾最多的 Region。
  • 通过-XX:InitiatingHeapOccupancyPercent控制触发 Mixed GC 的老年代占用阈值。

5. 优势与局限优势

1. 可预测的停顿时间：通过筛选回收价值最高的 Region，控制单次 GC 停顿时间。
2. 分代与分区结合：灵活管理不同生命周期的对象，减少碎片化。
3. 高效处理大对象：Humongous 区域专门存储超大对象，避免内存浪费。

局限

1. 内存占用：RSet 和 SATB 的写屏障增加内存和 CPU 开销。
2. 内存碎片：虽通过复制算法减少碎片，但 Humongous 对象可能导致 Region 利用率低。
3. 并发模式失败：若并发标记无法在停顿时间内完成，会触发 Full GC（使用 Serial Old 收集器）。

6. 参数调优

• 目标停顿时间：-XX:MaxGCPauseMillis（默认 200ms，需根据业务调整）。
• Region大小：-XX:G1HeapRegionSize（建议根据堆大小选择，如 4GB 堆可设为 16MB）。
• 并发线程数：-XX:ConcGCThreads（控制并发标记阶段的线程数）。

7. 与其他收集器对比

8. 面试高频问题

1. G1 如何实现低停顿？

   • 通过分区回收、筛选高垃圾比例 Region，以及并发标记与混合回收结合。

2. G1的 RSet 有什么作用？

   • 减少跨 Region 引用扫描，提升回收效率。

3. G1 的 SATB 算法如何工作？

   • 在并发标记开始时生成对象快照，通过写屏障记录引用变化，确保标记准确性。

4. G1 与 CMS 的适用场景差异？

   • G1 适合大堆且需平衡吞吐量与延迟的场景；CMS 适合中小堆且延迟敏感但对碎片不敏感的场景。

5. G1 的 Full GC 触发条件？

   • 并发标记失败（如超时）、Humongous 对象分配失败、显式调用System.gc()。

9. 总结

• 核心价值：G1 通过分区管理、并发标记和混合回收，在可控停顿时间内高效回收垃圾，是 JDK 9+ 的默认收集器。
• 面试重点：分代分区设计、SATB 与 RSet 机制、参数调优（如停顿时间与 Region 大小）。
• 避坑指南：避免过度调小MaxGCPauseMillis导致GC频繁，合理设置 Region 大小以适配应用对象分布。

 详见 G1 垃圾回收器。

• 栈：存放局部变量表、操作数栈、动态连接、方法出口等，线程私有。局部变量表存放了基本数据类型、对象引用类型、指向对象起始地址的引用指针、指向一个对象的句柄和 returnAddress 类型（指向了一条字节码指令的地址）。
• 本地方法栈：和虚拟栈相似，只不过它服务于 Native 方法，线程私有。
• 程序计数器：是一个较小的内存空间，当前线程所执行的行号指示器，用于记录正在执行的虚拟机字节指令地址，线程私有。唯一一块 Java 虚拟机没有规定任何 OutofMemoryError 的区块。
• 堆：Java 内存中最大的一块，所有对象实例、数组都存放在 Java 堆，GC 回收的地方，线程共享。
• 方法区：即非堆(元空间)，存放已被加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。各线程共享。回收目标主要是常量池的回收和类型的卸载。

 详见 运行时数据区域。

1. top → 定位高内存进程 (PID)。
2. top -Hp <PID> → 定位高内存线程 (TID)。
3. printf "%x\n" <TID> → 转为十六进制。
4. jstack <PID> | grep '0x4295' -C10 --color → 查看线程堆栈，关联业务代码。
5. jmap -dump:format=b,file=my.dump <PID> → 生成 Heap Dump。
6. MAT/VisualVM → 分析 Heap Dump 找到泄漏对象。
7. 修复代码 → 优化内存使用。
8. 监控验证 → 确保内存回归正常。

• 深入理解Java虚拟机JVM高级特性与最佳实践（第3版）.pdf
• 其他
  • tomcat类加载器为什么要破坏双亲委派机制？open in new window

• IDEA 插件
  • BinEd 文件二进制编码查看
  • jclasslib bytecode viewer