JVM

JVM运行时内存划分？程序计数器（PC寄存器）+虚拟机栈+本地方法栈+堆+方法区+JDK1.7与1.8区别
JVM运行时内存划分？

  1. 程序计数器

    1. 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。

    2. 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

    注意：程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。

  2. 虚拟机栈

    Java 虚拟机栈也是线程私有的，它的生命周期和线程相同，描述的是 Java 方法执行的内存模型，每次方法调用的数据都是通过栈传递的。

    Java 内存可以粗糙的区分为堆内存（Heap）和栈内存 (Stack),其中栈就是现在说的虚拟机栈，或者说是虚拟机栈中局部变量表部分。 （实际上，Java 虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息。）

    局部变量表主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。

    Java 虚拟机栈会出现两种错误：StackOverFlowError 和 OutOfMemoryError

    • StackOverFlowError： 若 Java 虚拟机栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 StackOverFlowError 错误。

    • OutOfMemoryError： 若 Java 虚拟机堆中没有空闲内存，并且垃圾回收器也无法提供更多内存的话。就会抛出 OutOfMemoryError 错误。

    Java 虚拟机栈也是线程私有的，每个线程都有各自的 Java 虚拟机栈，而且随着线程的创建而创建，随着线程的死亡而死亡。

  3. 本地方法栈

    和虚拟机栈所发挥的作用非常相似，本地方法栈也是线程私有的，区别是： 虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

    本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

    方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种错误。

  4. 堆

    Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。

    Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）.从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代。再细致一点有：Eden 空间、From Survivor、To Survivor 空间（新生代划分）等。进一步划分的目的是更好地回收内存，或者更快地分配内存。（默认的新生代（Young generation）、老年代（Old generation）所占空间比例为 1 : 2 ，默认新生代空间的分配：Eden : From : To = 8 : 1 : 1）

    JDK 8 版本之后方法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取而代之是元空间，元空间使用的是直接内存。

    大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

    堆这里最容易出现的就是 OutOfMemoryError 错误，并且出现这种错误之后的表现形式还会有几种，比如：

    1. OutOfMemoryError: GC Overhead Limit Exceeded ： 当JVM花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生此错误。

    2. java.lang.OutOfMemoryError: Java heap space :假如在创建新的对象时, 堆内存中的空间不足以存放新创建的对象, 就会引发java.lang.OutOfMemoryError: Java heap space 错误。(和本机物理内存无关，和你配置的内存大小有关！)

    3. ......

  5. 方法区

    方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。

    方法区也被称为永久代。方法区和永久代的关系很像 Java 中接口和类的关系，方法区是标准，而永久代是方法区的实现

    相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就“永久存在”了。

    JDK 1.8 的时候，方法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取而代之是元空间，元空间使用的是直接内存。

堆内存分配策略

内存分配策略主要有以下几点：

  • 对象优先分配在Eden区，如果Eden区没有足够的空间进行分配时，虚拟机执行一次MinorGC。

  • 大对象直接进入老年代（需要大量连续内存空间的对象）。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。

  • 长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄（Age Count）计数器，如果对象经过了1次Minor GC那么对象会进入Survivor区，之后每经过一次Minor GC那么对象的年龄加1，直到达到阀值（默认15次），对象进入老年区。

  • 动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代。

  • 空间分配担保。每次进行Minor GC时，JVM会计算Survivor区移至老年区的对象的平均大小，如果这个值大于老年区的剩余值大小则进行一次Full GC，如果小于检查HandlePromotionFailure设置，如果true则只进行Monitor GC,如果false则进行Full GC。

GC垃圾回收机制

分代垃圾回收

  • Minor GC：用于清理新生代（Eden）区域，Eden区满了就会触发一次Minor GC，清理无用对象，将有用对象复制到"Survivor1"，"Survivor2"区中（这两个区，大小空间相同，同一时刻Survivor1和Survivor2只有一个在用一个为空）。

  • Major GC：用于清理老年代区域。

  • Full GC：用于清理新生代，老年代区域，成本较高，会对系统性能产生影响。

Java 中的堆也是 GC 收集垃圾的主要区域。GC 主要分为两种：Minor GC、FullGC ( 或称为 Major GC )。

Minor GC

Minor GC 是发生在新生代中的垃圾收集动作，所采用的是复制算法。

当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳( 上面已经假设为 from 区域，这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定)，这些对象就会成为老年代。但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。

Full GC

Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法或标记-整理算法。

现实的生活中，老年代的人通常会比新生代的人"早死"。堆内存中的老年代(Old)不同于这个，老年代里面的对象，几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 "死掉" 了的。因此，Full GC 发生的次数不会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。

另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 ( 即不连续的内存空间 )，此后需要为较大的对象

分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。

Major GC

发生在永久代（方法区），这个区域不是用于存储那些从老年代存活下来的对象，这个区域也可能发生GC。只不过在这个区域发生GC的条件非常严苛，必须符合以下三种条件才会被回收：

  1. 所有实例被回收

  2. 加载该类的ClassLoader 被回收

  3. Class 对象无法通过任何途径访问（包括反射）

对象如何从新生代进入老年代？

大对象直接进入老年代

大对象是指需要大量连续内存空间的对象，例如很长的字符串以及数组。 虚拟机设置了一个-XX:PretenureSizeThreshold参数，令大于这个设置的对象直接在老年代分配。目的就是为了防止大对象在Eden空间和Survivor空间来回大量复制。

长期存活的对象进入老年代

虚拟机给每个对象定义了一个对象年龄(Age)计数器，如果对象在Eden区出生并经过第一次Mintor GC后仍然存活，并且能被Survivor接纳，并被移动到Survivor空间上，那么该对象年龄将被设置为1。对象在Survivor区中每熬过一次Minor GC,年龄就加一，当他的年龄增加到一定程度，就会被移动到老年代（年龄值默认为15）。对象晋升老年代的阈值可以通过-XX:MaxTenuringThreshold设置。

动态年龄判断并进入老年代

为了更好的适应不同程序的内存状况，虚拟机并不是永远要求对象的年龄必须达到MaxTenuringThreshold才会晋升到老年代。如果在Survivor空间中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需达到MaxTensuringThreshold的要求年龄。

Full GC触发条件
Minor GC触发条件

当Eden区满时，触发Minor GC。

Full GC触发条件：

  1. System.gc()方法的调用

此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI（Java远程方法调用）调用System.gc。

  1. 老年代空间不足

旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

  1. 方法区空间不足

JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息： java.lang.OutOfMemoryError: PermGen space 为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

  1. 通过Minor GC后进入老年代的平均大小大于老年代的可用内存

如果发现统计数据说之前Minor GC的平均晋升大小比目前old gen剩余的空间大，则不会触发Minor GC而是转为触发full GC

  1. 由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
如何判断对象是否存活？回收对象的两次标记过程。

  1. 引用计数法：

    给 Java 对象添加一个引用计数器，每当有一个地方引用它时，计数器 +1；引用失效则 -1，当计数器不为 0 时，判断该对象存活；否则判断为死亡（计数器 = 0）。

    优点：

    • 实现简单

    • 判断高效

    缺点：

    • 无法解决对象间相互循环引用 的问题（即该算法存在判断逻辑的漏洞）

  2. 引用链法（可达性分析法）：

    将一系列的 GC Roots 对象作为起点，从这些起点开始向下搜索。

    • 可作为 GC Root 的对象有： 1.Java虚拟机栈（栈帧的本地变量表）中引用的对象 2.本地方法栈 中 JNI引用对象 3.方法区 中常量、类静态属性引用的对象
    • 向下搜索的路径 = 引用链

    当一个对象到 GC Roots 没有任何引用链相连时，则判断该对象不可达

    没有任何引用链相连 = GC Root到对象不可达 = 对象不可用

    特别注意：

    • 可达性分析 仅仅只是判断对象是否可达，但还不足以判断对象是否存活 / 死亡

    • 当在 可达性分析 中判断不可达的对象，只是“被判刑” = 还没真正死亡

    不可达对象会被放在”即将回收“的集合里。

    • 要判断一个对象真正死亡，还需要经历两个阶段：

      1. 第一次标记 & 筛选

      2. 第二次标记 & 筛选

    第一次标记 & 筛选

    • 对象 在 可达性分析中 被判断为不可达后，会被第一次标记 & 准备被筛选

    a. 不筛选：继续留在 ”即将回收“的集合里，等待回收； b. 筛选：从 ”即将回收“的集合取出

    • 筛选的标准：该对象是否有必要执行 finalize( )方法

      1. 若有必要执行（人为设置），则筛选出来，进入下一阶段（第二次标记 & 筛选）；

      2. 若没必要执行，判断该对象死亡，不筛选 并等待回收

    当对象无 finalize()方法 或 finalize()已被虚拟机调用过，则视为“没必要执行”

    第二次标记 & 筛选

    当对象经过了第一次的标记 & 筛选，会被进行第二次标记 & 准备被进行 筛选

    该对象会被放到一个 F-Queue 队列中，并由 虚拟机自动建立、优先级低的Finalizer 线程去执行 队列中该对象的finalize()

    1. finalize()只会被执行一次
    1. 但并不承诺等待finalize()运行结束。这是为了防止 finalize()执行缓慢 / 停止 使得 F-Queue队列其他对象永久等待。

    筛选标准：

    在执行finalize()过程中，若对象依然没与引用链上的GC Roots 直接关联 或 间接关联（即关联上与GC Roots 关联的对象），那么该对象将被判断死亡，不筛选（留在”即将回收“集合里） 并 等待回收

垃圾回收算法以及垃圾回收器介绍，尤其是G1和CMS的优缺点

垃圾回收流程。

  1. 新建的对象，大部分存储在Eden中

  2. 当Eden内存不够，就进行Minor GC释放掉不活跃对象；然后将部分活跃对象复制到Survivor中（如Survivor1），同时清空Eden区

  3. 当Eden区再次满了，将Survivor1中不能清空的对象存放到另一个Survivor中（如Survivor2），同时将Eden区中的不能清空的对象，复制到Survivor1，同时清空Eden区

  4. 重复多次（默认15次）：Survivor中没有被清理的对象就会复制到老年区（Old）

  5. 当Old达到一定比例，则会触发Major GC释放老年代

  6. 当Old区满了，则触发一个一次完整的垃圾回收（Full GC）

  7. 如果内存还是不够，JVM会抛出内存不足，发生oom，内存泄漏。

垃圾回收算法

  1. Mark-Sweep（标记-清除）算法

    这是最基础的垃圾回收算法，之所以说它是最基础的是因为它最容易实现，思想也是最简单的。标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。

    这一算法有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。

  2. Copying（复制）算法

    为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。

    Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。

  3. 为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。

  4. 分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

    目前大部分垃圾收集器对于新生代都采取复制算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。

    而由于老年代的特点是每次回收都只回收少量对象，一般使用的是标记-整理算法（压缩法）（或者标记-清除算法）。

垃圾回收器

  1. Serial/Serial Old收集器 是最基本最古老的收集器，它是一个单线程收集器，并且在它进行垃圾收集时，必须暂停所有用户线程。Serial收集器是针对新生代的收集器，采用的是Copying算法，Serial Old收集器是针对老年代的收集器，采用的是Mark-Compact算法。它的优点是实现简单高效，但是缺点是会给用户带来停顿。

  2. ParNew收集器 是Serial收集器的多线程版本，使用多个线程进行垃圾收集。

  3. Parallel Scavenge收集器 是一个新生代的多线程收集器（并行收集器），它在回收期间不需要暂停其他用户线程，其采用的是Copying算法，该收集器与前两个收集器有所不同，它主要是为了达到一个可控的吞吐量。

  4. Parallel Old收集器 是Parallel Scavenge收集器的老年代版本（并行收集器），使用多线程和Mark-Compact算法。

  5. CMS（Current Mark Sweep）收集器 是一种以获取最短回收停顿时间为目标的收集器，它是一种并发收集器，采用的是Mark-Sweep算法。

  6. G1收集器 是当今收集器技术发展最前沿的成果，它是一款面向服务端应用的收集器，它能充分利用多CPU、多核环境。因此它是一款并行与并发收集器，并且它能建立可预测的停顿时间模型。

G1和CMS的优缺点

CMS是一款优秀的收集器，它的主要优点是：并发收集、低停顿，但他有以下3个明显的缺点：

优点：并发收集，低停顿

理由： 由于在整个过程和中最耗时的并发标记和 并发清除过程收集器程序都可以和用户线程一起工作，所以总体来说，Cms收集器的内存回收过程是与用户线程一起并发执行的

缺点：

1.CMS收集器对CPU资源非常敏感

在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程使应用程序变慢，总吞吐量会降低，为了解决这种情况，虚拟机提供了一种“增量式并发收集器”

的CMS收集器变种， 就是在并发标记和并发清除的时候让GC线程和用户线程交替运行，尽量减少GC 线程独占资源的时间，这样整个垃圾收集的过程会变长，但是对用户程序的影响会减少。（效果不明显，不推荐）

\2. CMS处理器无法处理浮动垃圾

CMS在并发清理阶段线程还在运行， 伴随着程序的运行自然也会产生新的垃圾，这一部分垃圾产生在标记过程之后，CMS无法再当次过程中处理，所以只有等到下次gc时候在清理掉，这一部分垃圾就称作“浮动垃圾” ，

\3. CMS是基于“标记--清除”算法实现的，所以在收集结束的时候会有大量的空间碎片产生。空间碎片太多的时候，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象的，只能提前触发 full gc。

为了解决这个问题，CMS提供了一个开关参数，用于在CMS顶不住要进行full gc的时候开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片没有了，但是停顿的时间变长了

与其他GC收集器相比，G1具备如下特点：

1、并行于并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

2、分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。它能够采用不同的方式去处理新创建的对象和已经存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果。

3、空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

4、可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和ＣＭＳ共同的关注点，但Ｇ１除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内

创建一个对象的步骤

  1. 检测类是否被加载：

    当虚拟机执行到new时，会先去常量池中查找这个类的符号引用。如果能找到符号引用，说明此类已经被加载到方法区（方法区存储虚拟机已经加载的类的信息），可以继续执行；如果找不到符号引用，就会使用类加载器执行类的加载过程，类加载完成后继续执行。

  2. 为对象分配内存：

    类加载完成以后，虚拟机就开始为对象分配内存，此时所需内存的大小就已经确定了。只需要在堆上分配所需要的内存即可。

    具体的分配内存有两种情况：第一种情况是内存空间绝对规整，第二种情况是内存空间是不连续的。

    • 对于内存绝对规整的情况相对简单一些，虚拟机只需要在被占用的内存和可用空间之间移动指针即可，这种方式被称为指针碰撞。

    • 对于内存不规整的情况稍微复杂一点，这时候虚拟机需要维护一个列表，来记录哪些内存是可用的。分配内存的时候需要找到一个可用的内存空间，然后在列表上记录下已被分配，这种方式成为空闲列表。

    分配内存的时候也需要考虑线程安全问题，有两种解决方案：

    • 第一种是采用同步的办法，使用CAS来保证操作的原子性。

    • 另一种是每个线程分配内存都在自己的空间内进行，即是每个线程都在堆中预先分配一小块内存，称为本地线程分配缓冲（TLAB），分配内存的时候再TLAB上分配，互不干扰。

  3. 为分配的内存空间初始化零值：

    对象的内存分配完成后，还需要将对象的内存空间都初始化为零值，这样能保证对象即使没有赋初值，也可以直接使用

  4. 对对象进行其他设置：（设置对象头）

    分配完内存空间，初始化零值之后，虚拟机还需要对对象进行其他必要的设置，设置的地方都在对象头中，包括这个对象所属的类，类的元数据信息，对象的hashcode，GC分代年龄等信息。这些信息存放在对象头中。 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。

  5. 执行 init 方法：

    执行完上面的步骤之后，在虚拟机里这个对象就算创建成功了，但是对于Java程序来说还需要执行init方法才算真正的创建完成，因为这个时候对象只是被初始化零值了，还没有真正的去根据程序中的代码分配初始值，调用了init方法之后，这个对象才真正能使用。

到此为止一个对象就产生了，这就是new关键字创建对象的过程。

image
详细介绍类加载过程

Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？

系统加载 Class 类型的文件主要三步:加载->连接->初始化。连接过程又可分为三步:验证->准备->解析。

image
加载

类加载过程的第一步，主要完成下面3件事情：

  1. 通过全类名获取定义此类的二进制字节流
  1. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
  1. 在内存中生成一个代表该类的 Class 对象，作为方法区这些数据的访问入口
验证

检查加载到的class文件的正确性

image
准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。

要注意的点：

  1. 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
  1. 这里所设置的初始值"通常情况"下是数据类型默认的零值（如0、0L、null、false等），比如我们定义了public static int value=111 ，那么 value 变量在准备阶段的初始值就是 0 而不是111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 fianl 关键字public static final int value=111 ，那么准备阶段 value 的值就被赋值为 111。
image
解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。也就是得到类或者字段、方法在内存中的指针或者偏移量。

符号引用就理解为一个标示，而直接引用直接指向内存中的地址。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行。

初始化

类加载的最后一步，是真正执行类中定义的 Java 程序代码(字节码)，初始化阶段是执行类构造器 <clinit> ()方法的过程。

双亲委派机制，使用这个机制的好处？破坏双亲委派机制的场景？如何破坏？
双亲委派机制

每一个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工作的时候会默认使用双亲委派机制。即在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则它才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为null时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。

image

注意：其实这个双亲翻译的容易让别人误解，我们一般理解的双亲都是父母，这里的双亲更多地表达的是“父母这一辈”的人而已，并不是说真的有一个 Mother ClassLoader 和一个 Father ClassLoader 。另外，类加载器之间的“父子”关系也不是通过继承来体现的，是由“优先级”来决定。

双亲加载机制的好处
  1. 隔离：不同类型的类由不同的类加载器进行加载，互不干预；
  1. 分级：加载的继承关系体现了 分级的关系模型；
  1. 安全：核心类 由 bootstrap class loader加载，不会被轻易替换/篡改；
  1. 加载：无重复加载，默认使用父类加载的类；
  1. 工程：简单、易懂、可维护，并且很容易扩展出自己的类加载器；
破坏双亲委派机制的场景？如何破坏？

双亲委派模型的作用：保证JDK核心类的优先加载；

如何破坏：

  1. 自定义类加载器，重写loadClass方法；
  1. 使用线程上下文类加载器

破坏的场景：参照https://www.pianshen.com/article/4541600181/

了解下tomcat的类加载机制

Tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。

双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。

tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的，还是要去顶层请求classloader.

JVM性能调优，常用命令，以及工具
性能调优
  • 线程池：解决用户响应时间长的问题
  • 连接池
  • JVM启动参数：调整各代的内存比例和垃圾回收算法，提高吞吐量
  • 程序算法：改进程序逻辑算法提高性能

具体参照：https://www.cnblogs.com/csniper/p/5592593.html

本章可参考：https://www.zhihu.com/question/28477388/answer/2247519738

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。