JVM面试

基本概念：JVM是可运行Java代码的假想计算机，包括一套字节码指令集，一组寄存器、一个栈、一个垃圾回收、堆和一个存储方法域。JVM运行在操作系统上，与硬件没有直接交互

运行过程：java源文件通过编译器生成相应的Class文件（字节码文件），字节码文件又通过Java虚拟机中的解释器编译成特定机器上的机器码

• ① Java 源文件 -> 编译器 -> 字节码文件
• ② 字节码文件 -> JVM -> 机器码

每一种平台的解释器是不同的，但是实现的虚拟机是相同的，这也就是为什么JAVA能够跨平台的原因。当一个程序开始运行，此时虚拟机开始实例化，多个程序启动就会存在多个虚拟机实例。程序退出或者关闭，则虚拟机实例消亡，多个虚拟机实例之间数据不能共享

线程

这里所说的线程指程序执行过程中的一个线程实体。JVM允许一个应用并非执行多个线程。Hotspot JVM中的Java线程与原生操作系统线程有直接的映射关系。当线程本地存储、缓冲区分配、同步对象、栈、程序计数器等准备好以后，就会创建一个操作系统原生线程。Java线程结束，原生线程随之被回收，操作系统负责调度所有线程，并把它们分配到任何可用的CPU上。当原生线程初始化完毕，就会调用Java线程的run()方法。当线程结束时，会释放原生线程和Java线程的所有资源

Hotspot JVM后台运行的系统线程主要有下面几个：

• 虚拟机线程（VM thread）：该线程等待 JVM 到达安全点操作出现。这些操作必须要在独立的线程里执行，因为堆修改无法进行时，线程需要JVM位于安全点。这些操作的类型有：stop-the-world 垃圾回收、线程栈 dump、线程暂停、线程偏向锁（biased locking）解除
• 周期性任务线程：该线程负责定时器事件（中断），用来调度周期性操作的执行
• GC线程：该线程支持JVM中不同的垃圾回收活动
• 编译器线程：该线程在运行时将字节码动态编译成本地平台相关的机器码
• 信号分发线程：该线程接收发送到JVM的信号并调用适当的JVM方法处理

JVM内存区域

Java内存区域主要分为线程私有区域（程序计数器、虚拟机栈、本地方法区）、线程共享区域（Java堆、方法区）、直接内存

• 线程私有数据区域生命周期与线程相同，依赖用户线程的启动/结束 而 创建/销毁（在Hotspot VM内），每个线程都与操作系统的本地线程直接映射，因此这部分内存区域的存/否跟随本地线程的生/死对应
• 线程共享区域随虚拟机的启动/关闭 而 创建/销毁
• 直接内存并不是JVM运行时数据区的一部分，但也会被频繁的使用：在JDK1.4引入的NIO提供了基于Channel 与 Buffer的IO方式。它可以使用Native函数库直接分配堆外内存，然后使用 DirectByteBuffer 对象作为这块内存的引用进行操作（详见：Java I/o 扩展），这样就避免了在java堆和Native堆中来回赋值数据，因此在一些场景中可以显著提高性能

程序计数器

线程私有，一块较小的内存空间，是当前线程所执行的字节码的行动指示器

正在执行java方法的话，计数器记录的是虚拟机字节码指令的地址（当前指令的地址），如果还是Native方法，则为空

这个内存区域是唯一一个在虚拟机中没有规定任何OutOfMemoryError情况的区域

虚拟机栈

线程私有，描述java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，都对应着一个栈帧在虚拟机栈中入栈到出栈的过程

栈帧是用来存储数据和部分过程结果的数据结构，同时也被用来出力动态链接（Dynamic Linking）、方法返回值和异常分配（Dispatch Exception）。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异常）都算作方法结束

本地方法区

线程私有，本地方法区和Java Stack作用类似，区别是虚拟机栈为执行Java方法服务，而本地方法栈则为Native方法服务，如果一个VM 实现使用C-linkage模型来支持Native调用，那么该栈将会使是一个C栈，但HotSpot VM 直接就把本地方法栈和虚拟机栈合二为一

堆

线程共享，创建的对象和数组都被保存在Java堆内存中，也是垃圾收集器进行垃圾收集的最重要的内存区域，由于现代VM采用分代收集算法，因此Java堆从GC角度还可以细分为：新生代（Eden区、From Survivor区、To Survivor区）、永久代

方法区

线程共享，我们常说的永久代（Permanent Generation），用于存储被 JVM 加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。HotSpot VM把GC分代收集扩展至方法区，即使用 Java堆的永久代来实现方法区，这样HotSpot的垃圾收集器就可以像管理Java堆一样管理这部分内存，而不必为方法区开发专门的内存管理器（永久代的内存回收的主要目标是针对常量池的回收和类型的卸载）

运行时常量池（Runtime Constant Pool）是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息时常量池（Constant Pool Table），用于存放编译器生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。Java虚拟机对Class文件的每一部分的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可，装载和执行

JVM运行时内存

Java堆从 GC的角度还可以细分为：新生代（Eden 区、From Survivor区、To Survivor）、老年代

新生代

用来存放新生的对象，一般占据堆的1/3空间，由于频繁创建对象，所以新生代会频繁发生Minor GC进行垃圾回收。新生代又分为Eden区、Servivor From、Servivor To三个区

• Eden区：Java新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代），当Eden区内存不够时就会触发 Minor GC，对新生区进行一次垃圾回收
• Servivor From：上一次GC的幸存者，作为这一次GC的被扫描者
• Servivor To：保留了一次MinorGC过程中的幸存者

Minor GC的过程（复制 -> 清空 -> 互换）

• 1、Eden、Servivor From复制到Servivor To，年龄+1
• 2、清空Eden、Servivor From
• 3、Servivor To与Servivor From互换

老年代

主要存放应用程序中生命周期长的内存对象

老年代比较稳定，Major GC不会频繁执行。在进行Major前一半都先进行了一次 Minor GC，使得有新生代的对象晋升老年代，导致空间不够用时才会触发，当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次Major GC进行垃圾回收腾出空间

Major GC采用标记清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没有标记对象，Major GC的耗时比较长，因为要扫描再回收，Major GC会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配，当老年代也满了装不下去时，就会抛出OOM（Out of Memory）异常

永久代

内存的永久保存区域，主要存放 Class 和 Meta（元数据）的信息，Class在被加载的时候被放入永久区域，它和存放实例的区域不同，GC不会在主程序运行期对永久区域进行清理，所以这也导致了永久代的区域会随着加载的Class增多而胀满，最终抛出OOM异常

在Java8总，永久代被移除，一个称为“元数据区”的区域取而代之。元空间的本质和永久代类似，元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，类的元数据放入native memory，字符串池和类的静态变量放入 java堆中，这样可以加载多少个类的元数据就不再由MaxPermSize控制，而由系统的实际可用空间来控制

垃圾回收与算法

如何确定垃圾

• 引用计数法：在Java中，引用和对象是有关联的，如果要操作对象则必须引用进行。因此，很显然一个简单的办法是通过引用计数法来判断一个对象是否可用回收。一个对象若没有任何与之关联的引用，即引用计数为0，则说明该对象不太可能再被用到，那么这个对象就是可回收的
• 可达性分析：为了解决引用计数法的循环引用问题，Java使用了可达性分析方法，通过一系列的“GC roots”对象作为起点搜索，如果在GC roots和一个对象之间没有可达路径，则称该对象是不可达的。注意：不可达对象变为可回收对象至少要经过两次标记过程，两次标记之后仍然是可回收对象，将面临回收

标记清除算法

Mark-Sweep，最基础的垃圾回收算法，分为两个阶段：标注、清除。标记阶段记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间

该算法的最大问题是：内存碎片化严重，后续可能发生大对象不能找到利用空间的问题

复制算法

Copying，为了解决Mark-Sweep算法内存碎片化缺陷而被提出的算法。按内存容量将内存划分为等大小的两块，每次只使用其中一块。当这一块内存满后将尚存活的对象赋值到另一块上去，把已使用的内存清掉

该算法实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原本的一半，且存活对象增多的话，Copying算法的效率会大大降低

标记整理算法

Mark-Compact，结合mark-Sweep和Copying的缺陷而提出。标记后将存活的对象移向内存的一段，然后清除边界外的对象

分代收集算法

分代收集算法是目前大部分JVM所采用的方法，其核心思想是根据对象存活的不同生命周期将内存划分为不同区域，一般情况下将GC堆划分为新生代和老年代

新生代与复制算法

目前大部分JVM的GC对于新生代都采用Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，要复制的操作较少。一般将新生代划分为一块较大的Eden空间和两个较小的Survivor空间（From，To），每次使用Eden空间和其中一块Survivor空间，当进行回收时，将两块空间中还存活的对象复制到另一块Survivor空间中

老年代与标记整理算法

老年代因为每次只回收少量对象，因而采用Mark-Compact算法

总结

• 1、Java虚拟机提到过的处于方法区的永生代（Permanet Generation），它用来存储class类，常量、方法描述等，对永生代的回收主要包括废弃常量和无用的类
• 2、对象的内存分配主要在新生代的Eden Space 和 Survivor Space 的 From Space(Survivor 目 前存放对象的那一块)，少数情况会直接分配到老生代
• 3、当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From Space 进行清理
• 4、如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代
• 5、在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环
• 6、对象在Survivor区域躲过一次GC后，其年龄就会 + 1，默认情况下年龄达到15的对象会被移到老生代

内存溢出与内存泄露

内存溢出

• Java虚拟机的堆内存设置不够
• 代码中创建了大量的大对象，并且长时间不能被垃圾收集器收集（存在引用）
• 在OOM之前，垃圾收集器会被触发，尽其所能区收集空间
  • 引用机制分析中，JVM回去尝试回收软引用指向的对象等
  • java.nio.Bits.reserveMemory()方法中，System.gc() 会被调用

内存泄露

概念：对象不会被程序用到，但是GC又不能回收它们

举例

• 单例模式：单例的生命周期和应用程序时一样长的，所以单例程序中，如果持有对象外部引用的话，那么这个外部对象时不能被回收的，则会导致内存泄漏的发生
• 提供close的资源未关闭：数据库连接、网络连接、IO连接必须手动close，否则不能回收

JAVA 四种引用类型

• 强引用：Java中最常见的引用，将一个对象赋给一个引用变量，当一个对象被强引用变量引用时，它处于可达状态，他是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到，JVM也不会回收，是造成Java内存泄露的主要原因之一
• 软引用：需要SoftReference类来实现，对于只有软引用的对象来说，系统内存足够时它不会被回收，当系统内存空间不足时将被回收，软引用通常用在对内存敏感的程序中
• 弱引用：需要WeakReference类来实现，比软引用的生存周期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管JVM的内存空间是否足够，都将回收该对象占用的内存
• 虚引用：需要PhantomReference类来实现，不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态

类型	回收时间	使用场景
强	一直存活，除非GC Roots不可达	所有程序的场景，基本对象，自定义对象等。
软	内存不足时会被回收	一般用在对内存非常敏感的资源上，用作缓存的场景比较多，例如：网页缓存、图片缓存
弱	只能存活到下一次GC前	生命周期很短的对象，例如ThreadLocal中的Key。
虚	随时会被回收， 创建了可能很快就会被回收	业界暂无使用场景， 可能被JVM团队内部用来跟踪JVM的垃圾回收活动

GC分代收集算法 VS 分区收集算法

分代收集算法

当前主流VM垃圾收集都采用分代收集算法，这种算法会根据对象存活周期的不同将内存划分为几块，如JVM中的新生代、老年代、永久代。这样就可以根据各年代特点采用最适当的GC算法

• 新生代-复制算法：每次垃圾收集都能发现大批对象已死，只有少量存活，因此选用复制算法，只需少量存活对象的复制成本就可以完成收集
• 老年的-标记整理算法：对象存活率高，没有额外空间对它进行分配担保，就必须采用标记-整理算法来进行回收，

分区收集算法

分区算法将整个堆空间划分为连续的不同小区间，每个小区间独立使用，独立回收，这样做的好处是可以控制一次回收多少个小区间，根据目标停顿时间，每次合理地回收若干个小区间，从而减少一次GC所产生的停顿

GC垃圾收集器

Java堆内存被划分为新生代和年老代两部分，新生代主要使用复制算法；年老代主要是标记整理算法，因此Java虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器，JDK1.6中Sun HotSpot虚拟机的垃圾收集器如下：

Serial垃圾收集器

单线程、复制算法。曾经是JDK1.3.1之前新生代唯一的垃圾收集器。Serial是一个单线程的收集器，它不但只会使用一个CPU或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程， 直到垃圾收集结束。

Serial简单高效，对于限定单个CPU环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器

ParNew垃圾收集器

Serial的多线程版本。除了使用多线程进行垃圾收集外，其余行为和Serial收集器完全已有，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程

ParNew收集器默认开启和CPU数目相同的线程数，可通过-XX：ParallelGCThreads参数来限制垃圾收集齐的线程数

ParNew垃圾收集器是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器

Parallel Scavenge收集器

新生代垃圾收集器，多线程复制。它重点关注程序达到一个可控制的吞吐量（Thoughput，CPU用于运行用户代码的时间/CPU总消耗时间，吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率利用CPU时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务，自适应调节策略也是ParallelScavenge 收集器与 ParNew 收集器的一个重要区别

Serial Old收集器

Serial垃圾收集器老年代版本，单线程、标记-整理算法。是运行在Clint的 java 虚拟机默认的年老代垃圾收集器

在Server模式下，主要有两个用途：

• 1、作为JDK1.5之前版本中与新生代的 Parallel Scavenge 收集器搭配使用
• 2、作为老年代使用CMS收集器的后备垃圾收集方案

新生代Serial与老年代Serial Old搭配垃圾收集过程图

新生代 Parallel Scavenge/ParNew 与年老代 Serial Old 搭配垃圾收集过程

Parallel Old收集器

Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在 JDK1.6 才开始提供

Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge 和年老代 Parallel Old 收集器的搭配策略

新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配运行过程

CMS收集器

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，主要目标：获取最短垃圾回收停顿时间，使用多线程的标记-清除算法

最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验

CMS工作机制如下：

• 初始标记：标记一下GC Roots能直接关联的对象，速度很快，暂停所有的工作线程
• 并发标记：进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程
• 重新标记：为了修正在并非标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象标记记录，暂停所有工作线程
• 并非清除：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程

由于耗时最长的并非标记和并非清除过程中，垃圾收集线程可以和用户一起并非工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行

G1收集器

Garbage first垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比于CMS收集器，G1收集器两个最突出的改进是：

• 基于标记-整理算法，不产生内存碎片
• 可以非常精确控制停顿时间，在不牺牲吞吐量的前提下，实现低停顿垃圾回收

G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域 的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收 集效率

JAVA IO

阻塞IO模型

最传统的一种IO模型，即在读写数据过程中会发生阻塞现象，当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。

典型的阻塞IO模型的例子为：data = socket.read()，若没有数据继续，就会一直阻塞在read方法

非阻塞IO模型

当用户线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。若结果是error时，就知道数据还没有准备好，它可再次发送read操作。一旦内核中的数据准备好了，且再次收到了用户线程的请求，那么它将马上将数据拷贝到用户线程，然后返回

用户线程需要不断地询问内核数据是否就绪，会一直占用CPU

while(true){
    data = socket.read();
    if(data!= error){
    处理数据
    break;
    }
}

多路复用IO模型

目前使用较多的模型，Java NIO实际上就是多路复用IO模型。一个线程不断轮询多个socket状态，当socket真正有多写事件时，才真正调用IO读写操作

多路复用IO模型中，只需要一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，只有在真正有socket读写事件进行时，才会使用IO资源，大大减少了资源占用

多路复用IO比非阻塞IO模型的效率高：多路复用IO——轮询每个socket状态是在内核，非阻塞IO——询问socket状态通过用户线程

注意：多路复用IO模型通过轮询来检测是否有事件到达，并且对到达的事件逐一相应。弱事件相应体很大，那么将导致后续的事件吃吃得不到处理，还会影响新的事件轮询

信号驱动IO模型

用户线程发起一个IO请求操作，给对应的socket注册一个信号函数，然后用户线程继续执行，当内核数据就绪时会发生一个信号给用户线程，用户线程接收信号随即在信号函数中调用IO读写操作来进行实际的IO请求操作

异步IO模型

最理想的IO模型，当用户线程发起read操作之后，离开就可以开始去做其它的事

从内核的角度，当它受到一个asynchronous read 之后，会立刻返回，说明read请求已经成功发起，因此不会对用户线程产生任何block。然后内核会等待数据准备完成，将数据拷贝到用户线程，当一起完成后，内核给用户线程发生一个信号，告知read操作完成。

JAVA NIO

NIO主要有三大核心部分：Channel（通道）、Buffer（缓存区）、Selector

NIO和传统IO之间的最大区别：IO面向流，NIO面向缓冲区

传统IO基于字节流和字符流操作；而NIO基于Channel和Buffer进行操作，数据总是 通道 <=> 缓冲区

Selector(选择区)用于监听多个通道的事件（比如：连接打开，数据到达）-> 单个线程也可监听多个数据通道

NIO的缓冲区

Java IO 面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何 地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。NIO 的缓冲导向方法不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有您需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据

NIO的非阻塞

IO 的各种流是阻塞的。这意味着，当一个线程调用 read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。 NIO 的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞 IO 的空闲时间用于在其它通道上执行 IO 操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）

Channel

Channel和IO中的Stream差不多一个等级。Stream是单向，而Channer是双向

NIO中的Channel的主要实现有：

• FileChannel
• DatagramChannel
• SocketChannel
• ServerSocketChannel

对应文件IO、UDP、TCP（Server和Client）

Buffer

缓冲区，实际上是一个容器，连续数组。Channel提供从文件、网络读取数据的渠道，但是读取或写入的数据必须经由Buffer

客服端发送数据，存入Buffer，再将Buffer中的内容写入通道，服务端通过Buffer从Channel中获取数据

在NIO中，Buffer是一个顶层父类，抽象类。常用Buffer的子类有：ByteBuffer、IntBuffer、 CharBuffer、 LongBuffer、 DoubleBuffer、FloatBuffer、 ShortBuffer

Selector

Selector 能够检测多个注册的通道上是否有事件发生，如果有事件发生，便获取事件然后针对每个事件进行相应的响应处理

是用一个单线程就可 以管理多个通道，也就是管理多个连接。这样使得只有在连接真正有读写事件发生时，才会调用 函数来进行读写，就大大地减少了系统开销，并且不必为每个连接都创建一个线程，不用去维护 多个线程，并且避免了多线程之间的上下文切换导致的开销

JVM类加载机制

JVM类加载分为五部分：加载、验证、准备、解析、初始化

• 加载：在内存中生产一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据入口。这里不一定非得从Class文件获取，还可以从ZIP中读取（如jar包、war包），也可以在运行时计算生成（动态代理），还可以从其他文件生产（JSP文件转换）
• 验证：确保Class文件的字节流中包含的信息是符合当前虚拟机的要求，并且不会危害虚拟机自身安全
• 准备：在方法区中分配这些变量所使用的内存空间
• 解析：虚拟机将常量池中的符号引用转换为直接引用的过程
  • 符号引用：引用的目标并不一定要已经加载到内存中，各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须一致
  • 直接引用：指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄，如果有了直接引用，那引用的目标必定已经在内存中存活
• 初始化：类加载最后一个阶段，开始真正执行类中定义的Java程序代码
  • 初始化阶段是执行类构造器方法的过程。方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证子方法执行之前，父类的方法已经执行完毕，如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成()方法

注意以下几种情况不会执行类初始化：

• 1、通过子类引用父类的静态字段，只会触发父类的初始化，不会触发子类的初始化
• 2、定义对象数组，不会触发该类的初始化
• 3、常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类
• 4、通过类名获取Class对象，不会触发类的初始化
• 5、通过Class.forName加载指定类时，如果指定参数initialize 为 false 时，也不会触发类初 始化，其实这个参数是告诉虚拟机，是否要对类进行初始化
• 6、通过ClassLoader默认的loadClass方法，也不会触发初始化动作

JVM类加载器

虚拟机设计团队把加载动作放到JVM外部实现，以便让应用程序决定如何获取所需的类，JVM提供了3种加载器

• 启动类加载器：负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath 参数指定路径中的，且被虚拟机认可（如 rt.jar）的类
• 扩展类加载器：负责加载 JAVA_HOME\lib\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库
• 应用程序类加载器：负载加载用户路径（classpath）上的类库

双亲委派

当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中， 只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己去加载

好处是：加载位于rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object 对象

OSGI

OSGi(Open Service Gateway Initiative)，是面向 Java 的动态模型系统，是 Java 动态化模块化系统的一系列规范

• 动态改变构造：OSGI服务平台提供多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGI技术提供一种面向服务的架构，它能使这些组件动态地发现对方
• 模块化编程与热插拔：OSGI旨在实现Java程序的模块化编程提供基础条件，基于OSGI的程序可以实现模块级的热插拔功能，当程序升级更新时，可以只停用、重新安装然后启动程序的其中一部分，这对企业级程序开发来说非常具有诱惑力的特性。OSGi 描绘了一个很美好的模块化开发目标，而且定义了实现这个目标的所需要服务与架构，同时 也有成熟的框架进行实现支持。但并非所有的应用都适合采用 OSGi 作为基础架构，它在提供强大 功能同时，也引入了额外的复杂度，因为它不遵守了类加载的双亲委托模型

原文链接