JVM整体结构及内存模型

试题回答参考思路：
1、堆结构
JVM的堆是运行时数据区，所有类的实例和数组都是在堆上分配内存。它在JVM启动的时候被创建。对象所占的堆内存是由自动内存管理系统也就是垃圾收集器回收。
堆内存是由存活和死亡的对象组成的，存活的对象是应用可以访问的，不会被垃圾回收。
死亡的对象是应用不可访问尚且还没有被垃圾收集器回收掉的对象。一直到垃圾收集器把这些对象回收掉之前，他们会一直占据堆内存空间。
2、永久代(Perm Gen space)
永久代主要存在类定义，字节码，和常量等很少会变更的信息。并且永久代不会发生垃圾回收，如果永久代满了或者超过了临界值，会触发完全垃圾回收（Full Gc）

• 永久代中一般包含：
• 类的方法(字节码…)
• 类名(Sring对象)
• .class文件读到的常量信息
• class对象相关的对象列表和类型列表 (e.g., 方法对象的array)
• JVM创建的内部对象
• JIT编译器优化用的信息

而在java8中，已经移除了永久代，新加了一个叫做元数据区的native内存区。
3、元空间
元空间和永久代类似，都是对JVM中规范中方法的实现。
不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。
因此，默认情况下，元空间的大小仅受本地内存的限制。
类的元数据放入native memory，字符串池和类的静态变量放入java堆中。这样可以加载多少类的元数据就不再由MaxPermSize控制，而由系统的实际可用空间来控制。
4、采用元空间而不用永久代的原因
为了解决永久代的OOM问题，元数据和class对象存放在永久代中，容易出现性能问题和内存溢出。
类及方法的信息等比较难确定其大小，因此对于永久代大小指定比较困难，大小容易出现永久代溢出，太大容易导致老年代溢出（堆内存不变，此消彼长）。
永久代会为GC带来不必要的复杂度，并且回收效率偏低。

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。 这是大佬写的， [7701页的BAT大佬写的刷题笔记，让我offer拿到手软]

当对象的所有引用被置为null时，这个对象确实成为了垃圾收集（GC）的候选对象，但垃圾收集器并不会立即释放这个对象所占用的内存。
在Java和许多其他管理内存的编程语言中，垃圾收集的执行并不是立即发生的，它依赖于垃圾收集器的算法和策略以及当前内存使用情况。
垃圾收集器通常在以下几种情况下运行：

1. 内存不足：当程序运行过程中可用内存不足时，垃圾收集器会被触发运行以回收无用的对象，从而释放内存。
2. 系统空闲：在系统不那么忙碌时，垃圾收集器可能会运行，以优化内存的使用和系统的响应。
3. 程序员请求：在某些语言中，程序员可以显式请求进行垃圾收集，虽然这不一定立即触发GC，但它可以增加GC运行的可能性。

因此，即使对象的引用被置为null，也不能保证垃圾收集器会立即运行来清理这些对象。实际上，具体的释放时间取决于垃圾收集器的实现细节和当前的内存状况。

首先，行收集器，也就是Serial GC，它是一个单线程的垃圾收集器。如下图：

这意味着它在执行垃圾收集时，会暂停所有其他应用线程，也就是我们常说的“Stop-the-World”暂停。
行收集器因为其简单和单线程的特性，非常适合于单核处理器或内存资源相对较小的环境中。
它通常用在客户端应用或者较小的服务器上。
然后是吞吐量收集器，也称为Throughput GC或Parallel GC，它使用多个线程来并行地进行垃圾收集。

这种方式可以有效地提高垃圾收集的速度，尤其是在多核处理器的环境下。
吞吐量收集器的目标是最大化应用的运行时间比例，减少垃圾收集占用的时间，从而提高整体的应用吞吐量。
这使得它非常适合那些对吞吐量要求较高的后端服务和大数据处理系统。
总的来说，选择哪种收集器，主要取决于你的应用场景和具体需求。如果是在资源有限或单核CPU的环境下，行收集器可能是个更好的选择。而在多核心和需要高吞吐量的环境下，吞吐量收集器则更加合适。

在Java中，一个对象是否可以被垃圾回收主要取决于是否还有活跃的引用指向这个对象。
具体来说，有几个条件可以使对象成为垃圾回收的候选者：

1. 无引用指向：当一个对象不再有任何活跃的引用指向它时，它就可以被垃圾回收。这是最常见的情况，比如当对象的引用被显式设置为null，或者引用所在的作用域结束时。
2. 循环引用：即使是两个或多个对象相互引用，但它们不再被其他活跃的引用或根对象引用时，这些对象也可以被视为垃圾并回收。Java的垃圾收集器可以识别这种情况。
3. 从可达性分析：Java使用可达性分析（Reachability Analysis）来确定对象是否存活。在这种分析中，一系列称为“根”（roots）的对象被用作起点，这通常包括活跃线程的栈帧中的本地变量、静态字段和特定的方法区域。从这些根出发，GC将标记所有可以访问到的对象。未被标记的对象，即那些从根节点出发无法到达的对象，被认为是可以回收的。

1. 弱引用和软引用：Java还提供了弱引用（WeakReference）和软引用（SoftReference）等机制，通过这些引用类型引用的对象可以在JVM需要内存时被垃圾回收器回收。弱引用的对象在垃圾收集时总是会被回收，而软引用的对象则在内存不足时会被回收。

因此，总结来说，一个Java对象在没有任何有效的引用指向它，或者只通过弱引用或软引用被访问时，就可以被视为垃圾并可能在下一次垃圾收集时被清理掉。这个过程依赖于垃圾收集器的具体实现和触发条件。

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。 这是大佬写的， [7701页的BAT大佬写的刷题笔记，让我offer拿到手软]

是的，在JVM的早期版本中，永久代是确实存在的，并且确实会发生垃圾回收。
永久代主要用来存储JVM加载的类信息、常量以及方法数据。尽管永久代中的对象通常有较长的生命周期，但它仍然可能涉及垃圾回收，特别是在类卸载的时候或者清理常量池中不再使用的数据时。
这种垃圾回收通常发生在进行全局垃圾收集（Full GC）的时候。
不过，需要注意的是，类的卸载和常量池的清理并不是特别频繁，因为它们的生命周期通常跟应用程序的生命周期一样长。
另外，从Java 8开始，Oracle的JVM不再使用永久代的概念了，转而使用元空间（Metaspace）来替代。

元空间不再使用JVM堆的一部分，而是直接使用本地内存。
在元空间中，仍然会发生垃圾回收，主要是为了清理不再使用的类元数据。
这种变化主要是为了提高性能以及更灵活地管理内存。
所以，如果我们谈论的是Java 8及以后的版本，那么应该关注元空间的垃圾回收，而不是永久代。

DGC叫做分布式垃圾回收。RMI使用DGC来做自动垃圾回收。
因为RMI包含了跨虚拟机的远程对象的引用，垃圾回收是很困难的。DGC使用引用计数算法来给远程对象提供自动内存管理。
分布式垃圾回收的工作原理基本上是通过跟踪网络中对象的引用来实现的。主要有以下几个步骤：

1. 引用跟踪：DGC系统会监控和记录每个对象在不同节点间的引用情况。每当一个节点对远程对象建立或解除引用时，这种改变会被记录下来。
2. 引用计数：DGC常用的一种方法是引用计数。每个对象会有一个与之相关的计数器，记录着对该对象的引用次数。当某个节点创建对另一个节点上对象的引用时，该对象的引用计数增加；当引用被释放时，引用计数减少。
3. 回收判定：当对象的引用计数归零时，意味着没有任何活跃的引用指向这个对象，此时该对象可以被回收。
4. 资源回收：一旦确定对象可以被回收，相关的垃圾回收操作会被触发，释放占用的资源。
5. 周期性检查：由于引用计数可能存在循环引用的问题，DGC系统通常会周期性地执行全局垃圾回收算法来检查和回收那些因为循环引用而未被清理的对象。

分布式垃圾回收面临的主要挑战是确保效率和准确性，特别是在大规模分布式系统中。延迟、网络分区和节点故障都可能影响DGC的准确性和性能。因此，实现一个高效且可靠的DGC机制是一个具有挑战性的任务，通常需要在系统设计阶段就进行细致的规划和测试。

1：Java虚拟机（JVM）一种用于计算机设备的规范，可用不同的方式（软件或硬件）加以实现。编译虚拟机的指令集与编译微处理器的指令集非常类似。Java虚拟机包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收堆和一个存储方法域。
Java虚拟机（JVM）是可运行Java代码的假想计算机。只要根据JVM规格描述将解释器移植到特定的计算机上，就能保证经过编译的任何Java代码能够在该系统上运行。
2：Java虚拟机是一个想象中的机器，在实际的计算机上通过软件模拟来实现。Java虚拟机有自己想象中的硬件，如处理器、堆栈、寄存器等，还具有相应的指令系统。
3：Java虚拟机规范定义了一个抽象的——而非实际的——机器或处理器。这个规范描述了一个指令集，一组寄存器，一个堆栈，一个“垃圾堆”，和一个方法区。一旦一个Java虚拟机在给定的平台上运行，任何Java程序（编译之后的程序，称作字节码）都能在这个平台上运行。Java虚拟机（JVM）可以以一次一条指令的方式来解释字节码（把它映射到实际的处理器指令），或者字节码也可以由实际处理器中称作just-in-time的编译器进行进一步的编译。

静态变量是类级别的变量，在Java中，它们随类一起加载。关于静态变量何时加载的问题，我们可以这样解释：
静态变量在运行期被加载和初始化。具体来说，它们是在类被Java虚拟机加载到内存中后、类被第一次引用时初始化的。这个过程是在运行时发生的，而非编译期。
完整的Java对象创建过程如下：

让我详细解释一下这个过程：

1. 类加载：首先，当Java程序运行时，Java虚拟机(JVM)通过类加载器加载包含静态变量的类。这一步涉及到查找字节码并从类的全路径名生成一个Class对象。
2. 链接：加载后，类进入链接阶段，这个阶段验证类中的字节码，为静态变量分配内存，并且可能将变量设置为默认值，如null、0或false。
3. 初始化：在链接阶段之后，类的初始化阶段开始。在这个阶段，静态变量按照它们在代码中出现的顺序显式初始化，如果它们有初始化表达式的话。此外，如果有静态初始化块（static block），它也会在这个时候执行。

这个初始化过程确保在任何静态方法或静态变量被访问之前，所有的静态变量已经被设置为指定的初始值。因此，虽然类的结构和静态变量的声明在编译期被确定并存储在类的字节码中，实际上它们的加载和初始化则发生在运行期。这种机制确保了Java类和对象的初始化顺序得到正确的管理和执行。

在Java虚拟机（JVM）中，确实有几种机制可以被视为内部的“缓存”功能，这些功能主要用于提高程序执行的效率和性能。
以下是几个例子：

1. 方法区（或元空间）：虽然方法区本身不是传统意义上的缓存，但它存储了类的结构信息，包括运行时常量池、字段和方法数据，以及方法的代码。这可以看作是一种缓存机制，因为它避免了每次执行时重新加载和解析类文件。
2. 字符串池（String Intern Pool）：JVM为了优化字符串存储和重用，维护了一个特殊的字符串池。当使用字面量创建字符串时，JVM首先检查池中是否已存在相同的字符串。如果存在，就返回现有的字符串引用，这样可以节省内存并提高性能。
3. 即时编译器（JIT）的代码缓存：JIT编译器在运行时将热点代码（即频繁执行的代码）编译成本地机器代码，以提高程序的执行速度。这些编译后的代码被存储在一个特定的缓存区域中，从而在后续的执行中可以直接使用，避免了重复的解释执行开销。
4. 堆中的缓存结构：某些应用可能会在JVM堆内显式创建缓存（如应用级的数据缓存），用于存储经常访问的数据对象。虽然这不是JVM自身维护的缓存，但是它是在JVM的管理下进行的。
5. Biased Locking：这是JVM用于优化对象锁的一种机制。通过偏向锁，JVM可以减少无竞争访问同步块时的锁开销，通过在对象头中缓存线程ID来实现。
6. 类加载器缓存：类加载器在加载类时，会缓存类信息，这样相同的类在下次加载时可以直接使用已缓存的数据，加快了类加载的速度。

对于8G内存，我们一般是分配4G内存给JVM，正常的JVM参数配置如下：

-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:SurvivorRatio=8

调优的话要具体场景具体分析，可以通过监控确认FullGC频率和次数，通过dump文件分析大对象等手段。
可以从代码层面优化或者是调整年轻代、老年代、幸存区的内存大小，来达到调优的目的

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。 这是大佬写的， [7701页的BAT大佬写的刷题笔记，让我offer拿到手软]

在 Java 中，堆和栈分别表示两种不同的内存分配方式，各自用于存储不同类型的数据和具有不同的管理机制。

在 64 位 JVM 中，int 数据类型的长度依然是 32 位（4 字节）。这在 Java 语言规范中有明确规定，不受运行环境的 32 位或 64 位体系结构的影响。
Java 基础数据类型的长度是固定的，独立于硬件架构：

• byte: 8 位（1 字节）
• short: 16 位（2 字节）
• int: 32 位（4 字节）
• long: 64 位（8 字节）
• char: 16 位（2 字节）
• float: 32 位（4 字节）
• double: 64 位（8 字节）

因此，在 64 位 JVM 中，int 仍然保持 32 位（4 字节）。

在 Java 虚拟机 (JVM) 中，Serial 垃圾收集器和 Parallel 垃圾收集器是两种不同的垃圾收集策略，它们的主要区别在于并发性和目标使用场景。

JVM 选项 -XX:+UseCompressedOops 主要用于 64 位 JVM 上的堆内存优化，简称为“压缩 OOP（普通对象指针）”

在 Java 中，可以通过检查系统属性 os.arch 来确定 JVM 是 32 位还是 64 位。该属性表示操作系统的体系结构。一般来说，如果属性值包含“64”，则表示是 64 位 JVM，否则是 32 位。
例如：

public class JVMArchitecture {public static void main(String[] args) {String architecture = System.getProperty("os.arch");System.out.println("JVM Architecture: " + architecture);if (architecture.contains("64")) {System.out.println("This is a 64-bit JVM.");} else {System.out.println("This is a 32-bit JVM.");}}
}

在 Java 中，JVM 最大堆内存的限制取决于虚拟机架构（32 位或 64 位）、操作系统和硬件资源
一般情况下，32 位和 64 位 JVM 的最大堆内存如下：

Java 堆空间（Heap）是 JVM 的一部分内存区域，用于存储由程序动态分配的所有对象。
它在 JVM 启动时创建，所有线程共享。垃圾收集器（GC）会在堆空间中自动管理内存，定期清理不再使用的对象。

在 Java 中，不能绝对保证垃圾收集（GC）在特定时间执行。
垃圾收集的行为由 JVM 控制，并根据具体的内存需求和配置参数自动决定何时触发。

在 Java 中，可以使用 Runtime 类或 Java Management Extensions (JMX) 来获取 Java 程序使用的内存和堆内存使用的百分比。

JVM 内存区域大致可以分为两种类型：堆（Heap）和非堆（Non-Heap）内存。

以下是一些主要的 JVM 关键名词及其解释：

1. 类加载器（Class Loader）：
   • 用于加载 Java 类文件到 JVM 中，并为每个类创建对应的 Class 对象。
   • 常见的类加载器有引导类加载器、系统类加载器和自定义类加载器。
2. 堆内存（Heap Memory）：
   • JVM 中用于存储 Java 对象的内存区域。
   • 包括新生代和老年代。
3. 新生代（Young Generation）：
   • 堆内存的一部分，存放新创建的对象，包含伊甸园区和两个幸存者区。
   • 对象在这里经常被垃圾收集器回收。
4. 老年代（Old Generation）：
   • 堆内存的一部分，存放生命周期较长的对象。
   • 从新生代晋升的对象存放在这里。
5. 元空间（Metaspace）：
   • 用于存储类的元数据，包括类的结构、字段、方法等。
   • 元空间在 Java 8 及以后版本中取代永久代，使用本地内存。
6. 垃圾收集器（Garbage Collector, GC）：
   • 自动管理内存，负责发现和回收不再使用的对象。
   • 常见的垃圾收集器包括 Serial、Parallel、CMS、G1 和 ZGC。
7. 栈（Java Stack）：
   • 每个线程的私有内存区域，存储线程运行时的栈帧，包括局部变量、操作数栈和方法调用信息。
8. 程序计数器（PC Register）：
   • 每个线程的私有区域，存储当前正在执行的指令地址。
9. 本地方法栈（Native Method Stack）：
   • 用于执行本地方法的栈空间，通常用于 JNI（Java Native Interface）。
10. 即时编译器（Just-In-Time Compiler, JIT）：

• 在运行时将字节码编译为机器码，以提高执行性能。

1. 逃逸分析（Escape Analysis）：

• 优化技术，用于分析对象的生命周期和作用域，以决定是否将对象分配在栈上而非堆上。

JVM 运行时内存主要划分为多个区域，每个区域用于不同类型的数据和任务。

在Java中，判断一个对象是否可以被视为垃圾，并由垃圾收集器（GC）回收，主要通过可达性分析（Reachability Analysis）来完成。这个方法不依赖于对象的引用计数，而是看对象是否可以从一组称为“GC Roots”的对象访问到。

在Java虚拟机（JVM）中，对象头（Object Header）是所有Java对象在内存中的重要组成部分。
对象头主要包含两个部分：标记字（Mark Word）和类型指针。对于数组类型的对象，还包括一个长度部分。

1. 标记-清除算法：
   • 首先标记不再使用的对象，然后清除它们。
   • 可能导致堆空间碎片化。

2. 标记-整理算法：
   • 在标记阶段之后，将存活的对象整理到堆的一端，再清除剩余的无用空间。

3. 标记-复制算法：
   • 将新生代分为两个区域，存活的对象从一个区域复制到另一个，原始区域被清空

1.类加载检查
虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
new指令对应到语言层面上讲是，new关键词、对象克隆、对象序列化等。
2.分配内存
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类 加载完成后便可完全确定，为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。
这个步骤有两个问题：
1.如何划分内存。
2.在并发情况下， 可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。
划分内存的方法：

• “指针碰撞”（Bump the Pointer）(默认用指针碰撞)

如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。

• “空闲列表”（Free List）

如果Java堆中的内存并不是规整的，已使用的内存和空 闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记 录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例， 并更新列表上的记录

解决并发问题的方法：

• CAS（compare and swap）

虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。

• 本地线程分配缓冲（Thread Local Allocation Buffer,TLAB）

把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存。通过**-XX:+/-UseTLAB参数来设定虚拟机是否使用TLAB(JVM会默认开启-XX:+UseTLAB**)，-XX:TLABSize 指定TLAB大小。

3.初始化零值
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）， 如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
4.设置对象头
初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。
5.执行方法
执行方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。

1. 垃圾收集器：

JVM的分代收集算法是基于一个核心观察：不同对象的生命周期不同。有些对象很快就变得不可达（如局部变量或临时对象），而有些则可能存活较长时间甚至贯穿整个应用程序的生命周期（如缓存数据或单例对象）。
根据这一观察，JVM的堆内存被分为几个不同的区域，以更有效地管理内存，从而优化垃圾收集性能。
主要包括以下几个部分：

JDK 1.8 相较于 JDK 1.7 在JVM方面进行了几项重要的优化和更新：

内存泄漏的发生方式可以按照其产生的原因和上下文进行分类。下面是几种常见的内存泄漏分类及其示例：

1**、内存溢出的可能原因 **

1. 内存中加载的数据量过于庞大，如一次从数据库取出过多数据；

2. 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

3. 代码中存在死循环或循环产生过多重复的对象实体；

4. 使用的第三方软件中的BUG；

5. 启动参数内存值设定的过小
   **2、内存溢出的解决方案： **
   第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
   第二步，检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。
   第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。
   **重点排查以下几点： **

6. 检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

7. 检查代码中是否有死循环或递归调用。

8. 检查是否有大循环重复产生新对象实体。

9. 检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。

10. 检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

在Java虚拟机（JVM）中，栈上分配和内存逃逸是两个与对象分配位置和性能优化相关的重要概念。
它们与JVM如何处理对象的内存分配和回收有关。

双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

确定适合服务器配置的 -Xmx（Java堆内存的最大值）需要考虑服务器的核心数和总内存，以及其他因素，如其他应用的内存需求、操作系统占用、JVM内部需求（如元空间、代码缓存等）和具体应用的内存需求。

Java8默认的垃圾收集器是Parallel Garbage Collector，也称为Parallel GC。

并行垃圾收集，是指使⽤多个GC worker 线程并行地执行垃圾收集，能充分利用多核CPU的能力，缩短垃圾收集的暂停时间。
工作流程如下：

除了单线程的GC，其他的垃圾收集器，比如 PS，CMS， G1等新的垃圾收集器都使用了多个线程来并行执行GC⼯作

在Java虚拟机（JVM）的垃圾收集过程中，“Stop-The-World”（STW）是一个非常重要的概念，它涉及到垃圾收集时对应用程序的影响。
此外，“安全点”（Safepoint）和"安全区域"（Safe Region）是与STW密切相关的机制，用于确保在执行垃圾收集时，应用程序的状态是一致且可预测的。

Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。
GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控
Java程序员不用担心内存管理，因为垃圾收集器会自动进行管理
**GC的触发 **
GC的触发通常由以下几种情况：

• 系统认为可用堆内存不足。
• 程序员手动调用System.gc()。
• JVM内部策略。

在Java虚拟机（JVM）中，程序计数器（Program Counter, PC）是一个较小的内存区域，它是JVM中的一种运行时数据区。程序计数器为每个正在执行的线程保留一个独立的空间，因此它也被称为“线程私有”的内存。

Java虚拟机栈（JVM Stack）是Java虚拟机用来存储线程执行Java方法（或称为函数）的内存模型的一部分。每个线程在Java虚拟机中都有自己的虚拟机栈，这个栈与线程同时创建。虚拟机栈的主要作用是管理Java程序中方法的调用和执行。

Java本地方法栈（Native Method Stack）是Java虚拟机（JVM）中的一个重要组成部分，它主要用于支持Java的本地方法执行。本地方法是指用Java以外的语言（如C或C++）编写的方法，这些方法通常是为了访问操作系统的底层资源，或者为了性能考虑而实现的。

JVM的方法区就像是一个图书馆，用来存放Java程序里所有类的信息。想象一下，每个类都是一本书，这些书里记录了类的结构，比如它有哪些方法（就是类里可以做的事情），有哪些变量等等。方法区还存放了这些方法的具体指令，也就是说，当你的程序运行时，它会来这个“图书馆”查找需要的信息。
除此之外，方法区还有一个特别的角落叫做“运行时常量池”，这里面存放的是一些常用的数字、字符串之类的常量信息，方便程序快速使用。
还有，方法区也负责存放静态变量。静态变量不像普通变量那样随着对象的创建而存在，它是跟着类一起加载的，可以被类的所有对象共享。
所以，你可以把方法区看作是存放所有类信息和部分特殊数据的地方，是程序能正确运行不可缺少的一部分。从Java 8开始，原来的方法区有了新名字，叫做元空间，但角色和功能基本没变。

运行时常量池（Runtime Constant Pool）是Java虚拟机（JVM）中的一部分，它属于每个类或接口的一部分。
简单来说，它的作用主要包括以下几点：

1. 存储字面量和符号引用：运行时常量池主要存储两类数据：字面量（如文本字符串、声明为final的常量值等）和符号引用（如类和接口的全限定名、字段的名称和描述符、方法的名称和描述符等）。
2. 支持动态链接：运行时常量池中的符号引用在类被加载后，会被转换为直接引用。这一过程称为动态链接，它有助于实现Java的多态和方法的调用。
3. 缓存：运行时常量池还可以看作是一种缓存，Java虚拟机通过这个常量池来重用相同的常量，这样可以节省内存空间并提高性能。

运行时常量池是每个类和接口的私有资产，它随着类或接口的加载而创建，在类或接口被卸载时销毁。简而言之，运行时常量池是一个类中固定和动态数据的存储空间，是实现Java代码在虚拟机中高效运行的关键组件之一。

JVM的直接内存（Direct Memory）不是Java虚拟机运行时数据区的一部分，而是在Java堆外分配的内存。这部分内存的使用与JVM的堆内存相互独立，主要有以下几个特点和作用：

1. 性能优化：直接内存通常用于在Java程序和操作系统之间传输大量数据时。使用直接内存可以显著提高性能，因为它能减少在Java堆和原生内存中数据传输时的复制过程。这是因为直接内存直接对原生（native）内存的操作，避开了JVM堆的干预。
2. NIO（New Input/Output）：直接内存最常见的使用场景是通过Java的NIO（New Input/Output）库，它允许Java程序通过所谓的“直接缓冲区”直接操作内存。这种方法主要用于高速的数据传输，如网络通信或文件I/O。
3. 内存管理：虽然直接内存的访问速度快于Java堆内存，但其分配和释放通常比堆内存要慢，并且其管理不像自动内存管理那样方便。直接内存的分配和释放通常需要通过编码手动控制。
4. 风险：直接内存的使用增加了内存泄漏的风险，因为它的生命周期不由JVM的垃圾收集器管理。不当的使用直接内存可能导致内存泄漏或系统崩溃。

总的来说，JVM的直接内存是一种高效的数据处理方式，适用于需要高性能I/O的场景。
然而，它的使用需要谨慎，以避免内存溢出等问题。

堆溢出（Heap Overflow）通常是指在Java虚拟机（JVM）中，当对象的内存分配需求超过了堆内存（Heap）的最大限制时发生的一种错误，这会导致OutOfMemoryError。具体原因可以从以下几个方面来理解：

1. 内存分配过大：单个对象或者请求的数组大小超过了JVM堆的最大限制。这种情况较为罕见，但在请求大量数据处理时可能会发生。
2. 对象长时间未被回收：程序中存在大量对象被长时间引用而不被释放，例如，对象被存储在全局集合中而没有适当的清除机制。这会导致JVM的堆内存中积累了大量不再需要的对象，从而耗尽内存。
3. 内存泄漏：应用程序代码中存在内存泄漏，即对象不再被使用后仍然被引用，垃圾收集器无法回收这些对象。例如，静态集合类属性如果被错误地使用，可能会无意中保持对对象的引用，阻止垃圾回收。
4. 垃圾收集器效率低：在某些情况下，垃圾收集器的回收效率不高，可能导致有效内存迅速耗尽，尤其是在内存使用高峰时。
5. 堆大小配置不当：JVM启动时堆的大小是可以配置的，如果堆的最大值设置得过小，随着应用程序运行和对象创建的增多，可用内存可能不足以支撑程序的需要。
6. 递归调用过深：虽然严格来说是栈溢出，但在一些使用大量递归的数据处理（如深度优先搜索）中，如果没有适当的终止条件或管理，也可能间接引起堆内存的过度使用。

栈溢出（Stack Overflow）是由于程序执行时栈内存空间被耗尽而引发的错误，常见于Java虚拟机（JVM）中。具体可能导致栈溢出的原因有下面几个可能的原因：

1. 深度递归调用：
   • 原因：递归调用中，每次方法调用时都会在调用栈上添加一个新的栈帧，包括局部变量和方法信息。如果递归没有及时退出或深度过大，会不断消耗栈空间。

例如：计算阶乘的递归函数，如果没有正确处理递归终止条件，可能导致栈溢出。

java
Copy code
public int factorial(int n) {if (n == 1) return 1;else return n * factorial(n - 1);
}

2. 大量嵌套或不断的方法调用：
   • 原因：方法调用过多也会逐渐消耗栈空间，尤其是在一些深层嵌套的调用场景中。

例如：多个方法相互调用，形成长链。

java
Copy code
public void method1() {method2();
}
public void method2() {method3();
}
public void method3() {method1();  // 如果调用关系复杂，可能导致调用链过长
}

3. 大量的局部变量：
   • 原因：每个方法的局部变量都会占用栈空间。如果一个方法中定义了大量的局部变量，尤其是数据占用较大的数组或对象，将快速耗尽栈空间。

例如：在方法内部定义一个大数组。

java
Copy code
public void largeLocalVariables() {int[] largeArray = new int[100000];  // 大数组占用栈空间// 使用数组
}

4. 栈帧过大：
   • 原因：每个方法调用都会创建一个栈帧，栈帧中包含局部变量表、操作数栈等信息。栈帧占用的空间过大会导致栈空间迅速耗尽。

例如：一个方法中有多个大数据类型的局部变量。

java
Copy code
public void largeStackFrame() {double[] largeDoubleArray = new double[10000];long[] largeLongArray = new long[10000];
}

5. JVM栈大小设置不当：
   • 原因：JVM启动时可以设置栈的最大大小。如果设置得过小，栈空间可能不足以支持正常的方法调用。

例如：在JVM启动参数中设置较小的栈大小，如 -Xss256k。

运行时常量池（Runtime Constant Pool）是每个类或接口的一部分，存储在Java虚拟机（JVM）的方法区内。
运行时常量池主要用于存储编译期生成的各种字面量和符号引用，这包括类和接口的全限定名、字段名、方法名及其他常量。
运行时常量池溢出是指这个存储区域由于存储的数据过多而超过了方法区的限制，导致OutOfMemoryError。
以下是造成运行时常量池溢出的几种原因：

1. 大量使用字符串常量和字符串拼接：
   • 在Java中，字符串常量都是存储在运行时常量池中的。如果程序中使用了大量的字符串常量，或者有大量的字符串拼接操作（特别是使用了**String.intern()**方法），这些字符串都会被存储在常量池中，可能会导致常量池快速填满。
2. 频繁使用String.intern()方法：
   • String.intern()是一个本地方法，它的作用是如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，会将此String对象包含的字符串添加到常量池中，并返回此String对象的引用。频繁使用这个方法可以使运行时常量池中的条目急剧增加。
3. 大量动态生成类：
   • 某些应用（如某些框架或动态代理技术）可能会动态生成大量的类。每一个类都可能有自己的运行时常量池，过多的类意味着需要更多的常量池空间。
4. 持续加载和卸载类：
   • 在一些Java应用中，特别是在容器环境如Tomcat中，频繁地加载和卸载类可能导致老的类在方法区（或PermGen space/Metaspace）中未被完全清理，这使得运行时常量池所占的空间不断增加。

好消息是，自Java 8起，运行时常量池已从永久代（PermGen）移至堆内存中的元空间（Metaspace），因此默认情况下，元空间的大小仅受系统可用内存的限制，运行时常量池溢出的情况有所减少，但在内存受限的环境中仍需谨慎管理内存使用，避免无节制的资源消耗。

方法区（Method Area），在Java虚拟机（JVM）中，主要用于存放已被虚拟机加载的类信息、常量、静态变量以及即时编译器编译后的代码等数据。
自Java 8起，传统的方法区（有时被称为永久代PermGen）被元空间（Metaspace）所取代。
方法区溢出，或在Java 8之后的版本中称为元空间溢出，主要由以下几个因素引起：

1. 大量加载类：
   • 在一些Java应用程序中，特别是使用动态生成类的框架（如某些OSGi环境、动态代理技术、热部署功能等），可能会加载大量的类到方法区。如果这些类不被卸载，它们会占据方法区的空间，最终可能导致方法区溢出。
2. 大量使用反射和代理：
   • 应用程序中大量使用反射、代理和CGLib这类字节码操作库，会动态生成很多运行时类，这些类如果长时间存在于方法区，也可能引起溢出。
3. 永久代/元空间大小限制：
   • 虽然元空间的大小受到物理内存的限制，但如果JVM启动时设置了元空间的大小限制较低，而应用程序又需要加载大量类和元数据，同样可能引起溢出。
4. 大量常量的创建：
   • 方法区也用于存储运行时常量池，如果程序中大量使用了常量，尤其是通过**String.intern()**方法存储了大量字符串，这同样可以耗尽方法区的空间。
5. 内存泄漏：
   • 如果类加载器不被垃圾收集器回收（例如，因为存在对这些类加载器的引用），那么加载的类也不会被卸载，从而导致方法区的内存泄漏。

解决方法区溢出的策略包括优化类加载的管理，避免过度使用反射和动态代理，适当增大方法区的大小设置，以及及时检测和处理可能的内存泄漏。对于使用较多第三方库和框架的复杂应用，需要特别注意这些方面的管理。

.分配内存
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。
对象所需内存的大小在类 加载完成后便可完全确定，为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。
这个步骤有两个问题：
1.如何划分内存。
2.在并发情况下， 可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。
**划分内存的方法： **
**1、“指针碰撞”（Bump the Pointer）(默认用指针碰撞) **
如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。
**2、“空闲列表”（Free List） **
如果Java堆中的内存并不是规整的，已使用的内存和空 闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记 录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例， 并更新列表上的记录

通常情况下，JVM对于对象内存分配确保了高度的线程安全性
解决并发问题的方法：

• CAS（compare and swap）

虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。

• 本地线程分配缓冲（Thread Local Allocation Buffer,TLAB）

把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存。通过**-XX:+/-UseTLAB参数来设定虚拟机是否使用TLAB(JVM会默认开启-XX:+UseTLAB**)，-XX:TLABSize 指定TLAB大小。

在Java虚拟机（JVM）中，对象的内存布局是标准化的，主要由以下几个组成部分构成：

1. 对象头（Object Header）：
   • 标记字段（Mark Word）：这部分用于存储对象自身的运行时数据，如哈希码、锁信息（锁状态标记）、线程持有的锁、偏向线程ID、偏向时间戳等。这些信息用于系统级的低级同步和垃圾回收。
   • 类型指针：这个指针指向对象所属类的元数据，JVM通过这个指针确定对象的类信息。在某些JVM实现中，这部分可能被优化掉，通过其他方式来确定对象类型。
2. 实例数据（Instance Data）：
   • 这部分存储对象的实际有效数据，包括各种字段。这些数据的排列顺序和数据类型都可能影响到内存的使用。通常，为了内存的有效利用和快速访问，相同宽度的字段会被分组在一起。
3. 对齐填充（Padding）：
   • 为了使对象的总大小是8字节的整数倍（这在大多数现代计算机系统中是一个优化选择），可能在实例数据之后加入一些对齐填充。对齐填充并不是必须的，只有当对象的总大小不是8字节倍数时，才会添加。

32位虚拟机对象头

64位虚拟机对象头

每个部分都有其特定功能和重要性，合理的布局可以优化对象的存取效率及降低内存的使用。例如：

• 对象头是关键部分，因为它包含了必要的元数据和同步信息，使得对象可以在JVM中安全有效地管理。
• 实例数据则是对象中存储的实际用户数据，是最核心的部分。
• 对齐填充虽然不包含实际信息，但它确保了内存访问的高效性。

在Java中，访问对象主要有以下几种方式，这些方式反映了Java虚拟机（JVM）如何从内存中定位和操作对象数据：

1. 使用句柄访问：
   • 在这种访问方式中，Java堆中会有一个句柄池。每个Java对象在堆上的分配都将有一个对应的句柄。这个句柄包含了对象数据与对象类型数据的引用。具体来说，当代码需要访问对象时，首先通过引用找到句柄，然后通过句柄找到对象数据和类型数据。这种间接访问的好处是，对象被移动时（例如在垃圾收集期间的压缩过程），只需改变句柄中的对象指针，而无需改变引用本身，这使得引用的更新成本较低。
2. 直接指针访问：
   • 在直接指针访问方式中，Java对象的引用直接指向对象数据的内存地址，同时，对象数据区域的起始部分包含了指向其类型数据的指针。这种方法减少了一次指针解引用的开销，提高了访问速度。对象移动时（如GC期间），需要更新所有的引用地址，这比句柄访问的成本更高，但访问速度更快。
3. 内联（Inline）访问：
   • 在一些高级的JVM实现中，特别是涉及即时编译器（JIT）优化时，可能会使用内联技术来优化对象访问。例如，方法中频繁访问的字段可以在方法调用时直接内联到调用者代码中，减少访问开销。内联是一种编译时优化，不仅限于对象访问，也用于方法调用。

例如，HotSpot JVM采用直接指针访问方式，因为它在大多数场景下提供了较好的性能平衡。

ZGC（Z Garbage Collector）是从Java 11开始引入的一种垃圾收集器，主要目标是为大型应用提供低延迟的垃圾回收解决方案。

ZGC设计的主要特点和目标包括：

• 支持TB量级的堆。我们生产环境的硬盘还没有上TB呢，这应该可以满足未来十年内，所有JAVA应用的需求了吧。
• 最大GC停顿时间不超10ms。目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右，Major GC一般都需要100ms以上（G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反），之所以能做到这一点是因为它的停顿时间主要跟Root扫描有关，而Root数量和堆大小是没有任何关系的。
• 奠定未来GC特性的基础。
• 最糟糕的情况下吞吐量会降低15%。这都不是事，停顿时间足够优秀。至于吞吐量，通过扩容分分钟解决。

另外，Oracle官方提到了它最大的优点是：

它的停顿时间不会随着堆的增大而增长！也就是说，几十G堆的停顿时间是10ms以下，几百G甚至上T堆的停顿时间也是10ms以下。

由于ZGC的这些特性，它特别适用于需要处理大规模数据且对延迟敏感的应用，如大数据分析、高频交易系统等。不过，由于ZGC在某些场景下可能会增加CPU的负担，并且对系统资源的管理（如内存页的管理）有更高的要求，因此在选择使用ZGC之前需要仔细评估应用的特性和需求。

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。 这是大佬写的， [7701页的BAT大佬写的刷题笔记，让我offer拿到手软]

以下是一些常用的JVM监控和调试工具：

1. VisualVM：
   • 免费工具，提供一窗口化界面，用于监控Java应用程序。它可以显示本地和远程JVM进程的详细性能数据，包括CPU、内存、线程和堆转储分析等。
2. JConsole：
   • Java自带的JMX（Java Management Extensions）客户端工具，用于监控基于Java的应用程序。它提供了关于内存使用、线程使用、类加载和JVM运行的实时数据。
3. Java Mission Control (JMC)：
   • 原先是Oracle的商业产品，现在作为OpenJDK的一部分免费提供。它包括Java Flight Recorder（JFR），可以用来收集低开销的详细运行时信息。
4. HeapDump：
   • 用于生成和分析Java堆转储的工具。堆转储包含了程序中所有对象的信息，包括类、字段、引用等，这对于诊断内存泄漏非常有用。
5. Eclipse Memory Analyzer (MAT)：
   • 一个功能强大的内存分析工具，用于查找内存泄漏和查看内存消耗的对象。它可以读取堆转储文件，并通过图形界面展示内存使用情况。
6. GCViewer：
   • 一个轻量级的工具，用于分析Java应用的垃圾收集行为。它可以读取JVM生成的GC日志，并生成易于理解的图表，帮助识别内存回收问题。
7. jstack：
   • 是一个命令行工具，用于生成Java应用程序中的当前线程快照。非常有用于分析线程死锁和其他线程相关问题。
8. jstat：
   • 命令行工具，用于监控垃圾收集和JVM编译的统计信息。
9. jmap：
   • 命令行工具，用于生成堆内存映射。它可以帮助开发者了解内存分配情况，特别是哪些对象占用了过多的堆空间。

类加载（Class Loading）是Java虚拟机（JVM）中将类的Class文件加载到内存中的过程，并为之生成对应的java.lang.Class对象。Java的类加载过程涉及到加载、链接和初始化三个主要步骤：

1. 加载（Loading）：
   • 在这一步，类加载器（ClassLoader）从文件系统、网络或其他来源读取Java类的二进制数据（.class文件），然后根据这些数据在JVM内部创建一个java.lang.Class对象。这个对象封装了类的元数据，包括类的名称、方法信息、字段信息等。
2. 链接（Linking）：
   • 链接过程又包括验证、准备和解析三个阶段：
     • 验证（Verification）：确保被加载的类符合Java语言规范和JVM规范，没有安全问题。
     • 准备（Preparation）：为类变量分配内存并设置类变量的默认初始值，这些变量使用的内存在方法区中分配。
     • 解析（Resolution）：将类、接口、字段和方法的符号引用转换为直接引用。
3. 初始化（Initialization）：
   • 在初始化阶段，JVM负责执行类构造器**()**方法的代码。这个方法由编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并产生。初始化阶段是执行这些代码，赋予类变量初始的正确值。

Java的类加载机制是动态的，类在首次被使用时才被加载，这就是Java中所说的“延迟加载”。这种机制帮助减少内存的使用，并且分散了类加载的负载，优化了应用的启动时间。

• 启动类加载器（Bootstrap ClassLoader）：负责加载JVM基础核心类库；
• 扩展类加载器（Extension ClassLoader）：负责加载扩展目录中的类库；
• 系统类加载器（System ClassLoader）：负责加载系统类路径（classpath）上的应用程序类。

开发者可以根据需要自定义类加载器，以实现特定的加载策略，比如从加密包中加载类，或者通过网络加载类等。这些自定义的加载器在遵循双亲委派模型（即先委派给父加载器尝试加载，失败后再由自身尝试加载）的前提下，提供了极大的灵活性。

Java内存模型（Java Memory Model，JMM） 是《Java虚拟机规范》中定义的一种用来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致性的内存访问效果的一种内存访问模型。从JDK５开始 JMM才正真成熟，完善起来。

Java内存模型的主要目的是定义程序中各种变量（Java中的实例字段，静态字段和构成数组中的元素，不包括线程私有的局部变量和方法参数）的访问规则。

Java内存模型规定了所有的变量都存储在主内存（Main Memory)。每条线程都有自己的工作内存（Working Memory），用来保存被该线程使用的变量的主内存副本。线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同线程之间无法之间访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

关于一个变量如何从工作内存拷贝到工作内存，如何从工作内存同步回主内存这一类的实现细节，Java内存模型中定义了以下8种操作来完成
。Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可在分的（对 double 和 long 类型的变量来说，load、store、read 和 write操作在某些平台上允许有例外）。

1. lock（锁定)：作用于主内存的变量，它把一个变量表示为一条线程独占的状态。
2. unlock（解锁)：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其它线程锁定。
3. read（读取)：作用域工作内存的变量，它把一个变量的值从工作内存传输到线程的工作内存中，以便随后的 load 使用。
4. load（载入)：作用于工作内存中的变量，它把 read 操作从主内存中得到的变量值放到工作内存中的变量副本中。
5. use（使用)：作用于工作内存中的变量，它把工作内存中的一个变量值传给执行引擎，每当虚拟机遇到一个需要使用变量值的字节码指令时将会执行这个操作。
6. assign（赋值)：作用于工作内存中的变量，它把一个从执行引擎接受的值赋给工作内存中的变量，每当虚拟机遇到一个需要使用变量赋值的字节码指令时执行此操作。
7. store（赋值)：作用于工作内存中的变量，它把工作内存中的一个变量传递到主内存中，以 write 操作使用。
8. write（赋值)：作用于主内存中的变量，他把 store 操作传递来的值放入到主内存的变量中。

Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

1. 不允许 read 和 load、store 和 write 操作之一单独出现。
2. 不允许一个线程丢弃它最近的assign操作，即一个变量在工作内存中被修改后必须把该变化同步回主内存。
3. 不允许一个线程无原因地（没有发生过任何 assign 操作）把数据从线程工作内存同步回主内存中。
4. 一个新的变量只能在主内存中 “诞生”，不允许在工作内存中直接使用一个未被初始化的（load 或 assign）的变量，即对一个变量实施 use 或 store 操作之前，必须先执行 load 或 assign操作。
5. 一个变量在同时个时刻治愈系一条线程对器进行 lock 操作，但 lock 操作可以被同一条线程重复执行多次，多次 lock 后，必须执行相同次数的 unlock 操作，变量才会被解锁。
6. 如果对一个变量执行 lock 操作，将会情况工作内存中的值，在执行引擎使用这个这个变量前，需要重新执行 load 或 assign 操作对 变量进行初始化。
7. 如果一个变量实现没有被 lock 操作锁定，那就不会允许对他执行 unlock 操作，也不允许去 unlock 一个被其它线程锁定的变量。
8. 对一个变量执行 unlock 操作前，必须先把此变量同步回主内存中（执行 store ,write 操作）

JVM（Java虚拟机）对Java的原生锁（synchronized关键字）进行了多种优化以提升性能，主要包括以下几种：

1. 偏向锁（Biased Locking）： 偏向锁是一种优化技术，用于减少没有竞争的同步块的开销。当锁被一个线程获取后，它会在锁对象的头部记录该线程的ID，表示该线程偏向于此锁。以后该线程进入和退出同步块时，不需要进行全面的锁释放和获取过程，只需要简单地检查锁对象头的标记即可。
2. 轻量级锁（Lightweight Locking）： 当锁是偏向锁，但检测到有其他线程尝试获取同一个锁时，偏向锁会升级为轻量级锁。轻量级锁通过在锁对象的头部存储锁记录（Lock Record）的指针，以及将线程栈帧中的一部分作为锁记录来实现。这种方式避免了操作系统层面的互斥，但仍涉及CAS操作（比较并交换）。
3. 重量级锁（Heavyweight Locking）： 如果轻量级锁失败（例如，有多个线程竞争相同的锁），则会升级为重量级锁。这种锁使用操作系统的互斥锁（如Mutex）来实现线程间的同步。这种锁的开销最大，但在高度竞争的环境下是必要的。
4. 锁消除（Lock Elision）： JVM通过静态分析代码，检测到某些锁其实并不是必须的（例如，一个被锁定的对象只能被一个线程访问），则可以完全消除这些锁。这种优化能减少不必要的同步开销。
5. 锁粗化（Lock Coarsening）： JVM还会在运行时进行锁粗化的优化。如果它检测到连续的锁定操作只操作同一个对象，它会将锁的范围扩大，将多个锁合并为一个范围更大的锁，以减少锁获取和释放的次数。

当Java程序出现内存溢出错误时，意味着程序在执行过程中申请的内存超过了Java虚拟机(JVM)分配给它的内存限制。为了排查和解决这个问题，以下是一些常用的排错步骤：
** 1、查看错误信息 **
首先，检查Java程序抛出的异常信息。通常，内存溢出错误会抛出java.lang.OutOfMemoryError异常，可能会伴随有其他的详细信息，如"Java heap space"(Java堆空间)或"PermGen space"(永久代空间)。
** 2、分析堆栈跟踪 **
查看堆栈跟踪以确定哪个部分的代码导致了内存溢出错误。堆栈跟踪将显示代码的调用层次结构，从中可以看到哪些方法在错误发生时被调用。
** 3、检查内存配置 **
确认Java虚拟机的内存配置是否合理。内存溢出错误可能是由于分配给Java堆、栈或永久代的内存不足所致。可以通过修改JVM启动参数中的-Xmx(最大堆内存)和-Xms(初始堆内存)选项来增加可用的内存。
** 4、检查代码逻辑 **
检查代码是否存在内存泄漏的情况。内存泄漏是指程序在不再使用某些对象时未能释放对它们的引用，导致这些对象无法被垃圾回收器回收。常见的内存泄漏情况包括未关闭的文件、未释放的数据库连接、长生命周期的缓存等。使用内存分析工具可以帮助确定是否存在内存泄漏问题。
** 5、调整内存使用 **
如果确认代码逻辑正确且没有明显的内存泄漏问题，可以尝试优化代码以减少内存使用。例如，使用合适的数据结构、及时释放不再使用的对象、避免创建过多的临时对象等。
Java出现内存溢出怎么排错？
** 6、增加硬件资源 **
如果经过以上步骤后仍然无法解决内存溢出问题，可能是因为程序的内存需求超过了系统的硬件资源限制。此时可以考虑增加物理内存或迁移到更高配置的服务器。
** 7、使用内存分析工具 **
Java提供了多种内存分析工具，如VisualVM、Eclipse Memory Analyzer等。这些工具可以帮助识别内存泄漏、查看对象的引用关系、分析内存使用情况等，有助于更深入地排查内存溢出问题。
**总结 **
在处理内存溢出错误时，重要的是要通过分析和排查确定导致问题的根本原因。这需要结合实际情况和调试工具来进行逐步排查，以找到解决方案并确保代码的稳定性和性能

Full GC（全面垃圾收集）是Java虚拟机（JVM）中清理内存的一种方式，它涉及到所有堆区域的清理，包括年轻代、老年代以及永久代（或元空间，取决于使用的JVM版本）。Full GC通常比较耗时，会暂停所有应用线程（即“Stop-The-World”），因此理解何时会触发Full GC对于优化Java应用性能非常重要。以下是一些常见的触发Full GC的情形：

1. 老年代空间不足： 当老年代（Old Generation）填满时，没有足够空间分配给即将晋升的对象，JVM会触发Full GC来清理老年代，释放空间。
2. 永久代或元空间不足： 如果使用的是较旧版本的JVM，可能会有永久代（PermGen），而在Java 8及以上版本，这个区域被替换为元空间（Metaspace）。这些区域存放类的元数据、常量池等。如果这些区域填满，也会触发Full GC。
3. System.gc()调用： 应用程序可以通过调用**System.gc()**请求JVM执行垃圾收集。虽然JVM可以忽视这个请求，但大多数情况下，这会触发Full GC。
4. JVM内部的GC算法要求： 根据JVM的垃圾回收器的选择和配置，例如CMS（Concurrent Mark-Sweep）回收器在无法并发清理足够空间时，会退回到Full GC。G1垃圾回收器在某些情况下也会进行全区域的清理。
5. 分配巨型对象失败： 在使用G1等垃圾回收器时，如果巨型对象（大于Region大小的对象）无法被分配到连续的空间中，可能会触发Full GC来释放足够的连续空间。
6. JVM启动参数： 某些JVM启动参数，如**-XX:+DisableExplicitGC**，可以控制由**System.gc()**引起的Full GC行为，而其他参数可能影响GC的行为和触发时机。

loadClass的类加载过程有如下几步：
加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载

• 加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
• 验证：校验字节码文件的正确性
• 准备：给类的静态变量分配内存，并赋予默认值
• 解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用，下节课会讲到动态链接
• 初始化：对类的静态变量初始化为指定的值，执行静态代码块

类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。
类加载器的引用：这个类到类加载器实例的引用
对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。 这是大佬写的， [7701页的BAT大佬写的刷题笔记，让我offer拿到手软]

对象的创建
对象创建的主要流程:

1.类加载检查
虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

new指令对应到语言层面上讲是，new关键词、对象克隆、对象序列化等。

2.分配内存
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类 加载完成后便可完全确定，为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。
这个步骤有两个问题：

1.如何划分内存。
2.在并发情况下， 可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。

划分内存的方法：
1、“指针碰撞”（Bump the Pointer）(默认用指针碰撞)

如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。

2、“空闲列表”（Free List）

如果Java堆中的内存并不是规整的，已使用的内存和空 闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记 录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例， 并更新列表上的记录

解决并发问题的方法：

• CAS（compare and swap）

虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。

• 本地线程分配缓冲（Thread Local Allocation Buffer,TLAB）

把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存。通过**-XX:+/-UseTLAB参数来设定虚拟机是否使用TLAB(JVM会默认开启-XX:+UseTLAB**)，-XX:TLABSize 指定TLAB大小。

3.初始化零值
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）， 如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
4.设置对象头
初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。
5.执行方法
执行方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。

类的生命周期包括这几个部分：
加载、连接、初始化、使用和卸载，其中前三部是类的加载的过程,加载，查找并加载类的二进制数据，在Java堆中也创建一个java.lang.Class类的对象
链接，链接又包含三块内容：验证、准备、初始化。
1）验证，文件格式、元数据、字节码、符号引用验证；
2）准备，为类的静态变量分配内存，并将其初始化为默认值；
3）解析，把类中的符号引用转换为直接引用初始化，为类的静态变量赋予正确的初始值使用，new出对象程序中使用卸载，执行垃圾回收

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

**64位虚拟机对象头： **

判断对象是否存活一般有两种方式：
**1、引用计数： **
每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。

此方法简单，无法解决对象相互循环引用的问题。

**2、可达性分析（Reachability Analysis）： **
从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，不可达对象。

下面列出一些常用的Java性能调优命令：

「对象一定分配在堆中吗？」 不一定的，JVM通过「逃逸分析」，那些逃不出方法的对象会在栈上分配。

**「什么是逃逸分析？」 **
逃逸分析(Escape Analysis)，是一种可以有效减少Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上。逃逸分析是指分析指针动态范围的方法，它同编译器优化原理的指针分析和外形分析相关联。当变量（或者对象）在方法中分配后，其指针有可能被返回或者被全局引用，这样就会被其他方法或者线程所引用，这种现象称作指针（或者引用）的逃逸(Escape)。通俗点讲，如果一个对象的指针被多个方法或者线程引用时，那么我们就称这个对象的指针发生了逃逸。
**
「逃逸分析的好处」 **
栈上分配，可以降低垃圾收集器运行的频率。同步消除，如果发现某个对象只能从一个线程可访问，那么在这个对象上的操作可以不需要同
步。标量替换，把对象分解成一个个基本类型，并且内存分配不再是分配在堆上，而是分配在栈上。这样的好处有，一、减少内存使用，因为不用生成对象头。二、程序内存回收效率高，并且GC频率也会减少。

在Java 8中，Java虚拟机（JVM）用元空间（Metaspace）替换了原先的永久代（PermGen，Permanent Generation）。
这一改变是为了解决永久代存在的几个问题并改进JVM的性能、可扩展性和可维护性。
下面是为什么使用元空间替换永久代的主要原因：

进行垃圾回收的过程中，会涉及对象的移动。为了保证对象引用更新的正确性，必须暂停所有的用户线程，像这样的停顿，虚拟机设计者形象描述为「Stop The World」。也简称为STW。
在HotSpot中，有个数据结构（映射表）称为「OopMap」。一旦类加载动作完成的时候，HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，记录到OopMap。在即时编译过程中，也会在「特定的位置」生成 OopMap，记录下栈上和寄存器里哪些位置是引用。
这些特定的位置主要在：
1.循环的末尾（非 counted 循环）
2.方法临返回前 / 调用方法的call指令后
3.可能抛异常的位置
这些位置就叫作「安全点(safepoint)。」 用户程序执行时并非在代码指令流的任意位置都能够在
停顿下来开始垃圾收集，而是必须是执行到安全点才能够暂停。

一般情况下，JVM的对象都放在堆内存中（发生逃逸分析除外）。
当类加载检查通过后，Java虚拟机开始为新生对象分配内存。
如果Java堆中内存是绝对规整的，所有被使用过的的内存都被放到一边，空闲的内存放到另外一边，中间放着一个指针作为分界点的指示器，所分配内存仅仅是把那个指针向空闲空间方向挪动一段与对象大小相等的实例，这种分配方式就是 指针碰撞。

如果Java堆内存中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，不可以进行指针碰撞啦，虚拟机必须维护一个列表，记录哪些内存是可用的，在分配的时候从列表找到一块大的空间分配给对象实例，并更新列表上的记录，这种分配方式就是空闲列表。

可以把内存分配的动作按照线程划分在不同的空间之中进行，每个线程在Java堆中预先分配一小块内存,这就是TLAB（Thread Local Allocation Buffer，本地线程分配缓存） 。虚拟机通过 -XX:UseTLAB 设定它的。

1. 如果你的堆大小不是很大（比如 100MB ），选择串行收集器一般是效率最高的。
   参数： -XX:+UseSerialGC
2. 如果你的应用运行在单核的机器上，或者你的虚拟机核数只有单核，选择串行收集器依然是合适的，这时候启用一些并行收集器没有任何收益。
   参数： -XX:+UseSerialGC 。
3. 如果你的应用是“吞吐量”优先的，并且对较长时间的停顿没有什么特别的要求。选择并行收集器是比较好的。
   参数： -XX:+UseParallelGC 。
4. 如果你的应用对响应时间要求较高，想要较少的停顿。甚至 1 秒的停顿都会引起大量的请求失败，那么选择 G1 、 ZGC 、 CMS 都是合理的。虽然这些收集器的 GC 停顿通常都比较短，但它需要一些额外的资源去处理这些工作，通常吞吐量会低一些。
   参数：
   -XX:+UseConcMarkSweepGC
   -XX:+UseG1GC
   -XX:+UseZGC 等。
   从上面这些出发点来看，我们平常的 Web 服务器，都是对响应性要求非常高的。选择性其实就集中在 CMS 、 G1 、 ZGC 上。而对于某些定时任务，使用并行收集器，是一个比较好的选择

当 tomcat启动时，会创建几种类加载器： Bootstrap 引导类加载器 加载 JVM启动所需的类，以及标准扩展类（位于 jre/lib/ext 下） System 系统类加载器 加载 tomcat 启动的类，比如bootstrap.jar，通常在 catalina.bat 或者 catalina.sh 中指定。位于 CATALINA_HOME/bin 下

tomcat的几个主要类加载器：

• commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
• catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
• sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
• WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见，比如加载war包里相关的类，每个war包应用都有自己的WebappClassLoader，实现相互隔离，比如不同war包应用引入了不同的spring版本，这样实现就能加载各自的spring版本；

从图中的委派关系中可以看出：
CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。

safepoint又叫安全点
比如 GC 的时候必须要等到 Java 线程都进入到 safepoint 的时候 VMThread 才能开始
执行 GC，

1. 循环的末尾 (防止大循环的时候一直不进入 safepoint，而其他线程在等待它进入safepoint)
2. 方法返回前
3. 调用方法的 call 之后
4. 抛出异常的位置