掌握JVM一篇就够了！

最新推荐文章于 2024-01-27 16:36:42 发布

gosling1024

最新推荐文章于 2024-01-27 16:36:42 发布

阅读量243

点赞数 1

分类专栏：架构文章标签： jvm java

本文链接：https://blog.csdn.net/qq_28261811/article/details/117690828

版权

架构专栏收录该内容

2 篇文章 0 订阅

订阅专栏

001，jvm的运行时数据区

不同虚拟机的运行时数据区可能略微有所不同，但都会遵从 Java 虚拟机规范， Java 虚拟机规范规定的区域分为以下 5 个部分：

程序计数器（Program Counter Register）：当前线程所执行的字节码的行号指示器，字节码解析器的工作是通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能，都需要依赖这个计数器来完成；

Java 虚拟机栈（Java Virtual Machine Stacks）：用于存储局部变量表、操作数栈、动态链接、方法出口等信息；

本地方法栈（Native Method Stack）：与虚拟机栈的作用是一样的，只不过虚拟机栈是服务 Java 方法的，而本地方法栈是为虚拟机调用 Native 方法服务的；

Java 堆（Java Heap）：Java 虚拟机中内存最大的一块，是被所有线程共享的，几乎所有的对象实例都在这里分配内存；

方法区（Methed Area）：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。

002、OOM异常类型

1，栈溢出

方法递归调用。

2，堆溢出：java heap space

对象无法回收。

3，堆溢出：GC overhead limit exceeded

4，堆溢出：Direct buffer memory

5，堆溢出：unable to create new native thread

创建了多个线程（linux 1024，实际小于这个数值）。

修改：

6，堆溢出：matespace

003、哪些对象以及死亡？

1，引用技术法

给对象中添加一个引用计数器，当每有一个地方应用它时，计数器值加1；当引用失效时，计数器值减1；任何时刻计数器为0的对象就是不可能被使用（死亡状态）。这个计数算法实现简单，判断效率也高，但是出现两个实例相互引用并且没有其他地方引用这两个对象的情况，那么这两个对象实际上已经是死亡状态，可是计算器的值不为0，存在误判的，会导致内存溢出。

2，可达性分析法

现在jvm就是通过可达性分析来判断对象是否存活的。基本思路是通过一系列称为“GC Roots”的对象作为起始点，从这些点开始向下搜索，搜索所经过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，证明此对象是不可用的（死亡状态）。

004、哪些对象可以作为GC Roots？

虚拟机栈中引用的对象比如：各个线程被调用的方法中使用到的参数、局部变量等。
本地方法栈内JNI（通常说的本地方法）引用的对象方法区中类静态属性引用的对象（1.7后存储在heap中）比如：Java类的引用类型静态变量
方法区中常量引用的对象比如：字符串常量池（string Table）里的引用
所有被同步锁synchroni zed持有的对象
Java虚拟机内部的引用。基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutOfMemoryError），系统类加载器。
反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等
除了这些固定的GCRoots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（Partial GC）。
如果只针对Java堆中的某一块区域进行垃圾回收（比如：典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一.并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性。比如：只回收new space 时需要将 old space中的指向也考虑进去。

上面列了那么多，其实就是想说，因为Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root。即将堆外，所有对于堆的指向都考虑到GC Roots中。

注意:

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。如同事物的一致性一样，即一个业务中操作，就是此时不能有其他业务操作改变GC Root 的连接。也就是保证每个GC Root的对象引用业务的一致性。（STW）
这点也是导致GC进行时必须"StopTheWorld"的一个重要原因。
➢即使是号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

005、四种引用

1、JAVA 强引用

在 Java 中最常见的就是强引用，把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它处于可达状态，它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到 JVM 也不会回收。因此强引用是造成 Java 内存泄漏的主要原因之一。

2、JAVA软引用

软引用需要用 SoftReference 类来实现，对于只有软引用的对象来说，当系统内存足够时它不会被回收，当系统内存空间不足时它会被回收。软引用通常用在对内存敏感的程序中。

3、JAVA弱引用

弱引用需要用 WeakReference 类来实现，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管 JVM 的内存空间是否足够，总会回收该对象占用的内存。

4、JAVA虚引用

虚引用需要 PhantomReference 类来实现，它不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态。

006、可达性分析判断不可达的对象是非死不可吗？

达性分析算法中不可达的对象，并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

1、对象在进行可达性分析后被发现不可达，它将会被第一次标记并进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法，当对象没有覆盖finalize()方法或者finalize()方法已经被JVM调用过，那么就没必要执行finalize()方法；如果被判定为有必要执行finalize()方法，那么此对象将会放置在一个叫做F-Quenen的队列之中，并在稍后由一个虚拟机自动建立的、低优先级的Finalize线程去触发这个方法。

2、稍后GC将对F-Quenen中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关系即可，譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量，那么在第二次标记时它将被移出“即将回收”集合；finalize()方法是对象逃脱死亡的最后一次机会，如果对象这时候还没有成功逃脱，那他就会真的被回收了。

007、方法区回收

很多人以为方法区（或者HotSopt VM中的元空间或者永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且性价比一般较低，在对的新生代生一般能回收70%~95%的空间，而方法区远低于此。

方法区的垃圾手机主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常相似。以常量池中字面量的回收为例，若字符串“abc”已经进入常量池中，但当前系统没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用该字面量，若发生内存回收，且必要的话，该“abc”就会被系统清理出常量池。常量池中其他的类（接口）、方法、字段的符号引用与此类似。

无用的类需要满足3个条件：

（1）该类所有的实例都已经被回收，即Java堆中不存在该类的任何实例；

（2）加载该类的ClassLoader已经被回收；

（3）该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，此处仅仅是“可以”，而并不是和对象一样（不使用了就必然回收）

008、垃圾器分代收集理论

当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”（Generational Collection）的理论进行设计，分代收集名为理论，实质是一套符合大多数程序运行实际情况的经验法则，它建立在两个分代假说之上：

1）弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是朝生夕灭的。

2）强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消亡。

这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。

009、垃圾收集算法

当成功区分出内存中存活对象和死亡对象后,GC接下来的任务就是执行垃圾回收,释放掉无用对象所占用的内存空间,以便有足够的可用内存空间为新对象分配内存。目前在JVM中比较常见的三种垃圾收集算法是标记-清除算法(Mark-Sweep)、复制算法(Copying)、标记-整理算法(Mark-Compact)。

1、标记-清除算法

当堆中的有效内存空间(available memory)被耗尽的时候,就会停止整个程序(也被称为stop the world),然后进行两项工作,第一项则是标记,第二项则是清除。

标记: Collector从引用根结点开始遍历,标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
清除: Collector对堆内存从头到尾进行线性的遍历,如果发现某个对象在其Header中没有标记为可达对象,则将其回收。

缺点

效率不算高，如果堆中包含大量的对象，并且是需要回收的，势必需要大量的标记与清除工作。
在进行GC的时候,需要停止整个应用程序,导致用户体验差
这种方式清理出来的空闲内存是不连续的,产生内存碎片。需要维护一个空闲列表

何为清除: 这里所谓的清除并不是真的置空,而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时,判断垃圾的位置空间是否够,如果够,就存放。

2、标记-复制算法

为了解决标记一清除算法在垃圾收集效率方面的缺陷（需要两步才能清除：标记，清除），将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。

优点：

复制过去以后保证空间的连续性，不会出现“碎片”问题。

缺点：

此算法的缺点也是很明显的，就是需要两倍的内存空间，且同时有一个内存空间是浪费的。

如果系统中的垃圾对象很多，那么复制算法处理起来就很麻烦了,复制算法还是需要在复制的存活对象数量并不会太大，或者说非常低才行情况下才使用。在新生代中，对象往往朝生夕死，死亡率很高，存活的对象相对很少，所以是适用这种复制算法。在新生代，对常规应用的垃圾回收，一次通常可以回收98%的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代。

3、标记-整理算法

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。标记一清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。标记一压缩（Mark一Compact）算法由此诞生。

第一阶段和标记一清除算法一样，从根节点开始标记所有被引用对象.
第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。
之后，清理边界外所有的空间。

标记一压缩算法的最终效果等同于标记一清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记一清除一压缩（Mark一 Sweep一Compact）算法。
二者的本质差异在于标记一清除算法是一种非移动式的回收算法，标记一压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

优点

消除了标记一清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。
消除了复制算法当中，内存减半的高额代价。

缺点

从效率上来说，标记一整理算法要低于复制算法。
移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址。移动过程中，需要全程暂停用户应用程序。即：STW（StopTheWorld）

010、常见的垃圾回收器

011、内存分配与回收策略

1、对象在Eden区分配

大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次Minor GC。我们来进行实际测试一下。

在测试之前我们先来看看 Minor GC和Full GC 有什么不同呢？

Minor GC/Young GC：指发生新生代的的垃圾收集动作，Minor GC非常频繁，回收速度一般也比较快。
Major GC/Full GC：一般会回收老年代，年轻代，方法区的垃圾，Major GC的速度一般会比Minor GC的慢10倍以上。

Eden与Survivor区默认8:1:1

大量的对象被分配在eden区，eden区满了后会触发minor gc，可能会有99%以上的对象成为垃圾被回收掉，剩余存活的对象会被挪到为空的那块survivor区，下一次eden区满了后又会触发minor gc，把eden区和survivor区垃圾对象回收，把剩余存活的对象一次性挪动到另外一块为空的survivor区，因为新生代的对象都是朝生夕死的，存活时间很短，所以JVM默认的8:1:1的比例是很合适的，让eden区尽量的大，survivor区够用即可，

JVM默认有这个参数-XX:+UseAdaptiveSizePolicy(默认开启)，会导致这个8:1:1比例自动变化，如果不想这个比例有变化可以设置参数-XX:-UseAdaptiveSizePolicy。

2、大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。

比如设置JVM参数：-XX:PretenureSizeThreshold=1000000 (单位是字节) -XX:+UseSerialGC ，再执行下上面的第一个程序会发现大对象直接进了老年代

为什么要这样呢？为了避免为大对象分配内存时的复制操作而降低效率。

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

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。

如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

4、对象动态年龄判断

当前放对象的Survivor区域里(其中一块区域，放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年龄判断机制一般是在minor gc之后触发的。

5、老年代空间分配担保机制

年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间，如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)的参数是否设置了。如果有这个参数，就会看看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次Full gc，对老年代和年轻代一起回收一次垃圾，如果回收完还是没有足够空间存放新的对象就会发生"OOM"。当然，如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，那么也会触发full gc，full gc完之后如果还是没有空间放minor gc之后的存活对象，则也会发生“OOM”

012、如何查下看默认的垃圾回收器

java -XX:+PrintCommandLineFlags -version

D:\code\crawler-code\common-api-service>java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=132296320 -XX:MaxHeapSize=2116741120 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndivid
ualAllocation -XX:+UseParallelGC
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)

默认是：ParallelGC

013、常用JVM基本配置参数

-Xmx：最大分配内存，默认为物理内存的1/4

-Xms：初始分配内存，默认为物理内存的1/64

-Xss：等价于-XX:ThreadStackSize，单个线程栈空间大小，默认一般为512k-1024k，通过jinfo查看为0时，表示使用默认值

-Xmn：设置年轻代大小

-XX:MetaspeaceSize：设置元空间大小（默认21M左右，可以配置大一些），元空间的本质可永久代类似，都是对JVM规范中方法区的实现，不过元空间与永久代的最大区别在于：元空间不在虚拟机中，而是使用本地内存，因此，默认情况下，元空间大小仅受本地内存大小限制

典型设置案例：

-Xms128m -Xmx4096m -Xss1024k -XX:MetaspaceSize=512m -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseSerialGC

014、死锁查看

public class DeadLockTest {
   private static Object lock1 = new Object();
   private static Object lock2 = new Object();
   public static void main(String[] args) {
      new Thread(() -> {
         synchronized (lock1) {
            try {
               System.out.println("thread1 begin");
               Thread.sleep(5000);
            } catch (InterruptedException e) {
            }
            synchronized (lock2) {
               System.out.println("thread1 end");
            }
         }
      }).start();
      new Thread(() -> {
         synchronized (lock2) {
            try {
               System.out.println("thread2 begin");
               Thread.sleep(5000);
            } catch (InterruptedException e) {
            }
            synchronized (lock1) {
               System.out.println("thread2 end");
            }
         }
      }).start();
      System.out.println("main thread end");
   }
}

jstack 进程ID

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00000000186f34e8 (object 0x00000000d637fdf8, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00000000186f0ba8 (object 0x00000000d637fe08, a java.lang.Object),
  which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
        at com.enbrands.api.databank.MustDeadLock.run(MustDeadLock.java:43)
        - waiting to lock <0x00000000d637fdf8> (a java.lang.Object)
        - locked <0x00000000d637fe08> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at com.enbrands.api.databank.MustDeadLock.run(MustDeadLock.java:30)
        - waiting to lock <0x00000000d637fe08> (a java.lang.Object)
        - locked <0x00000000d637fdf8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
Found 1 deadlock.

015、CPU飙升，如何定位代码

1，使用命令top -p pid ，显示你的java进程的内存情况，pid是你的java进程号，比如19663

2，按H，获取每个线程的内存情况

3，找到内存和cpu占用最高的线程tid，比如19664

4，转为十六进制得到 0x4cd0，此为线程id的十六进制表示

5，执行 jstack 19663|grep -A 10 4cd0，得到线程堆栈信息中 4cd0 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法

6，查看对应的堆栈信息找出可能存在问题的代码。

016、常见的命令

如果是在生产环境中直接排查 JVM 的话，最简单的做法就是使用 JDK 自带的 6 个非常实用的命令行工具来排查。它们分别是：jps、jstat、jinfo、jmap、jhat 和 jstack，它们都位于 JDK 的 bin 目录下，可以使用命令行工具直接运行。

1、JPS

-l：用于输出运行主类的全名，如果是 jar 包，则输出 jar 包的路径；
-q：用于输出 LVMID（Local Virtual Machine Identifier，虚拟机唯一 ID）；
-m：用于输出虚拟机启动时传递给主类 main() 方法的参数；
-v：用于输出启动时的 JVM 参数。

2、jstat

jstat（JVM Statistics Monitoring Tool，虚拟机统计信息监视工具）用于监控虚拟机的运行状态信息。

例如，我们用它来查询某个 Java 进程的垃圾收集情况，示例如下：

●-class，查询类加载器信息；

●-compiler，JIT 相关信息；

●-gc，GC 堆状态；

●-gcnew，新生代统计信息；

●-gcutil，GC 堆统计汇总信息。

3、jinfo

jinfo <option><pid>

jinfo -flags 45129
VM Flags:
-XX:CICompilerCount=3 -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:MaxNewSize=1431306240 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=89128960 -XX:OldSize=179306496 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC

其中 45129 是使用 jps 查询的 LVMID。我们可以通过 jinfo -flag [+/-]name 来修改虚拟机的参数值，比如下面的示例：

➜  jinfo -flag PrintGC 45129 # 查询是否开启 GC 打印
-XX:-PrintGC
➜  jinfo -flag +PrintGC 45129 # 开启 GC 打印
➜  jinfo -flag PrintGC 45129 # 查询是否开启 GC 打印
-XX:+PrintGC
➜  jinfo -flag -PrintGC 45129 # 关闭 GC 打印
➜  jinfo -flag PrintGC 45129 # 查询是否开启 GC 打印
-XX:-PrintGC

4、jmap

1、直接生成堆快照文件

➜  jmap -dump:format=b,file=/Users/admin/Documents/2020.dump 47380
Dumping heap to /Users/admin/Documents/2020.dump ...
Heap dump file created

2、自动生成dump文件

也可以设置内存溢出自动导出dump文件(内存很大的时候，可能会导不出来)

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./ （路径）

3、此命令可以用来查看内存信息，实例个数以及占用内存大小

jmap -histo 14660 #查看历史生成的实例
jmap -histo:live 14660 #查看当前存活的实例，执行过程中可能会触发一次full gc

num：序号
instances：实例数量
bytes：占用空间大小
class name：类名称，[C is a char[]，[S is a short[]，[I is a int[]，[B is a byte[]，[[I is a int[][]

4、堆信息

017、JVM运行情况预估

用 jstat gc -pid 命令可以计算出如下一些关键数据，有了这些数据就可以采用之前介绍过的优化思路，先给自己的系统设置一些初始性的JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。

1、年轻代对象增长的速率

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率。

2、Young GC的触发频率和每次耗时

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC 公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

3、每次Young GC后有多少对象存活和进入老年代

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

4、Full GC的触发频率和每次耗时

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。

优化思路其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。尽量别让对象进入老年代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响。

018、内存溢出的情况

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

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

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

（4）长连接未关闭，或者长连接不断建立。

019、年轻代为什么被划分成eden、survivor区？

020、年轻代为什么釆用的是复制算法？

021、老年代为什么采用的是标记清除、标记整理算法

022、线上环境问题排查？（有做过哪些GC调优？）

1、如果对于服务有监控，那么相关指标会在达到阈值的时候进行报警，收到报警信号号，查看服务状态

2，一般查看服务进程号之后，查看CPU、内存、磁盘使用情况

3，如果是CPU使用较高、一般要找到对应线程和代码

4、如果是内存使用较高，那么需要使用jmap -heap查看内存使用情况，jstat -gc pid 1000 10动态查看内存、GC的情况,jmap -histo 查看对象实例个数及大小

5、也可以生成dump文件，通过可视化工具查看

6、如果已经发生内存溢出，有的情况是这个内存确实收回不了。（不断建立连接，智能网管）

7、有的情况是需要调整年轻代大小，或者是查询批量数据的时候，减少每次查询的大小。（云积分圈人）

023、系统频繁Full GC导致系统卡顿是怎么回事

机器配置：2核4G
JVM内存大小：2G
系统运行时间：7天
期间发生的Full GC次数和耗时：500多次，200多秒
期间发生的Young GC次数和耗时：1万多次，500多秒

大致算下来每天会发生70多次Full GC，平均每小时3次，每次Full GC在400毫秒左右；每天会发生1000多次Young GC，每分钟会发生1次，每次Young GC在50毫秒左右。

-Xms1536M -Xmx1536M -Xmn512M -Xss256K -XX:SurvivorRatio=6  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M 
-XX:+UseParNewGC  -XX:+UseConcMarkSweepGC  -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly

大家可以结合对象挪动到老年代那些规则推理下我们这个程序可能存在的一些问题，经过分析感觉可能会由于对象动态年龄判断机制导致full gc较为频繁。

jstat -gc 13456 2000 10000

对于对象动态年龄判断机制导致的full gc较为频繁可以先试着优化下JVM参数，把年轻代适当调大点：

 -Xms1536M -Xmx1536M -Xmn1024M -Xss256K -XX:SurvivorRatio=6  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

优化完发现没什么变化，full gc的次数比minor gc的次数还多了。

我们可以推测下full gc比minor gc还多的原因有哪些？

1、元空间不够导致的多余full gc

2、显示调用System.gc()造成多余的full gc，这种一般线上尽量通过-XX:+DisableExplicitGC参数禁用，如果加上了这个JVM启动参数，那么代码中调用System.gc()没有任何效果

3、老年代空间分配担保机制
最快速度分析完这些我们推测的原因以及优化后，我们发现young gc和full gc依然很频繁了，而且看到有大量的对象频繁的被挪动到老年代，这种情况我们可以借助jmap命令大概看下是什么对象

查到了有大量User对象产生，这个可能是问题所在，但不确定，还必须找到对应的代码确认，如何去找对应的代码了？

1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)

2、如果生成User对象的地方太多，无法定位具体代码，我们可以同时分析下占用cpu较高的线程，一般有大量对象不断产生，对应的方法代码肯定会被频繁调用，占用的cpu必然较高

可以用上面讲过的jstack或jvisualvm来定位cpu使用较高的代码

024、常用的 JVM 调优的参数都有哪些？

堆设置

- -Xms:初始堆大小
- -Xmx:最大堆大小
- -XX:NewSize=n:设置年轻代大小
- -XX:NewRatio=n:设置年轻代和年老代的比值。默认为2.，表示年轻代与年老代比值为1：2，年轻代占整个年轻代年老代和的1/3
- -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。默认为8，表示Eden：Survivor=8：2，一个Survivor区占整个年轻代的1/10
- -XX:MaxMetaspaceSize=n:设置持久代大小

收集器设置

- -XX:+UseSerialGC:设置串行收集器
- -XX:+UseParallelGC:设置并行收集器
- -XX:+UseParalledlOldGC:设置并行年老代收集器
- -XX:+UseConcMarkSweepGC:设置并发收集器

垃圾回收统计信息

- -XX:+PrintGC
- -XX:+PrintGCDetails
- -XX:+PrintGCTimeStamps
- -Xloggc:filename

并行收集器设置

- -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
- -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
- -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

并发收集器设置

- -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
- -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

025、Java8 内存分代的改进

在 JDK 1.8 中， HotSpot 已经没有 “PermGen space”这个区域了，取而代之是一个叫做 Metaspace（元空间）的东西。实际上在JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，

譬如符号引用(Symbols)转移到了native heap；

字面量(interned strings)转移到了java heap；

类的静态变量(class statics)转移到了java heap。
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。

因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：
　-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
　-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集。
　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集。

取消永久代的原因：
（1）字符串存在永久代中，容易出现性能问题和内存溢出。
（2）类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
（3）永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

026、JVM中什么时候会进行垃圾回收？

1、当年轻代或者老年代满了，Java虚拟机无法再为新的对象分配内存空间了，那么Java虚拟机就会触发一次GC去回收掉那些已经不会再被使用到的对象

2、手动调用System.gc()方法，通常这样会触发一次的Full GC以及至少一次的Minor GC

3、程序运行的时候有一条低优先级的GC线程，它是一条守护线程，当这条线程处于运行状态的时候，自然就触发了一次GC了。

当年轻代内存满时，会引发一次普通GC，该GC仅回收年轻代。需要强调的时，年轻代满是指Eden代满，Survivor满不会引发GC

当年老代满时会引发Full GC，Full GC将会同时回收年轻代、年老代

当永久代满时也会引发Full GC，会导致Class、Method元信息的卸载

027、我们可以主动垃圾回收吗？

GC本身是会周期性的自动运行的,由JVM决定运行的时机,而且现在的版本有多种更智能的模式可以选择,还会根据运行的机器自动去做选择,就算真的有性能上的需求,也应该去对GC的运行机制进行微调,而不是通过使用这个命令来实现性能的优化。

每个 Java 应用程序都有一个 Runtime 类实例，使应用程序能够与其运行的环境相连接。可以通过 getRuntime 方法获取当前运行。java.lang.System.gc()只是java.lang.Runtime.getRuntime().gc()的简写，两者的行为没有任何不同。唯一的区别就是System.gc()写起来比Runtime.getRuntime().gc()简单点. 其实基本没什么机会用得到这个命令, 因为这个命令只是建议JVM安排GC运行, 还有可能完全被拒绝。

028、Stop-The-World（STW）

GC在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉，即GC停顿，会带给用户不良的体验；为什么要Stop-The-World？可达性分析的时候为了确保快照的一致性，需要对整个系统进行冻结，不可以出现分析过程中对象引用关系还在不断变化的情况，也就是Stop-The-World。

Stop-The-World是导致GC卡顿的重要原因之一。串行和并行都会导致STW，并发不会导致STW。

029、什么样的对象是可以回收的？

030、什么情况下使用堆外内存？要注意些什么？堆外内存如何被回收？

JVM启动时分配的内存，称为堆内存，与之相对的，在代码中还可以使用堆外内存，比如Netty，广泛使用了堆外内存，但是这部分的内存并不归JVM管理，GC算法并不会对它们进行回收，所以在使用堆外内存时，要格外小心，防止内存一直得不到释放，造成线上故障。

JDK的ByteBuffer类提供了一个接口allocateDirect(int capacity)进行堆外内存的申请，底层通过unsafe.allocateMemory(size)实现，最底层是通过malloc方法申请的，但是这块内存需要进行手动释放，JVM并不会进行回收，幸好Unsafe提供了另一个接口freeMemory可以对申请的堆外内存进行释放。

如果每次申请堆外内存，都需要在代码中显示的释放，对于Java这门语言的设计来说，显然不够合理，既然JVM不会管理这些堆外内存，它们是如何回收的呢？

DirectByteBuffer

JDK中使用DirectByteBuffer对象来表示堆外内存，每个DirectByteBuffer对象在初始化时，都会创建一个对用的Cleaner对象，这个Cleaner对象会在合适的时候执行unsafe.freeMemory(address)，从而回收这块堆外内存。

当初始化一块堆外内存时，对象的引用关系如下：

其中first是Cleaner类的静态变量，Cleaner对象在初始化时会被添加到Clener链表中，和first形成引用关系，ReferenceQueue是用来保存需要回收的Cleaner对象。如果该DirectByteBuffer对象在一次GC中被回收了

此时，只有Cleaner对象唯一保存了堆外内存的数据（开始地址、大小和容量），在下一次FGC时，把该Cleaner对象放入到ReferenceQueue中，并触发clean方法。Cleaner对象的clean方法主要有两个作用：

1、把自身从Clener链表删除，从而在下次GC时能够被回收

2、释放堆外内存

public void run() {
    if (address == 0) {
        // Paranoia
        return;
    }
    unsafe.freeMemory(address);
    address = 0;
    Bits.unreserveMemory(size, capacity);
}

如果JVM一直没有执行FGC的话，无效的Cleaner对象就无法放入到ReferenceQueue中，从而堆外内存也一直得不到释放，内存岂不是会爆？其实在初始化DirectByteBuffer对象时，如果当前堆外内存的条件很苛刻时，会主动调用System.gc()强制执行FGC。

不过很多线上环境的JVM参数有-XX:+DisableExplicitGC，导致了System.gc()等于一个空函数，根本不会触发FGC，这一点在使用Netty框架时需要注意是否会出问题。

031、什么是类加载器，类加载器有哪些?

实现通过类的权限定名获取该类的二进制字节流的代码块叫做类加载器。classloader顾名思义，即是类加载。虚拟机把描述类的数据从class字节码文件加载到内存，并对数据进行检验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

1、引导类加载器 bootstrap class loader　　

启动类加载器主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分，它负责将 /lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中，注意必由于虚拟机是按照文件名识别加载jar包的，如rt.jar，如果文件名不被虚拟机识别，即使把jar包丢到lib目录下也是没有作用的(出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

2、扩展类加载器 extensions class loader

　　它负责加载JAVA_HOME/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者可以直接使用标准扩展类加载器。

3、应用程序类加载器 application class loader

　　应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是我们经常用到的classpath路径，开发者可以直接使用系统类加载器，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。

4、自定义类加载器 java.lang.classloder

　　就是自定义啦，通过继承java.lang.ClassLoader类的方式

5、类加载器之间的关系

　　启动类加载器（BootstrapClassLoader），由C++实现，没有父类。

　　拓展类加载器(ExtClassLoader)，由Java语言实现，父类加载器为BootstrapClassLoader

　　系统类加载器(AppClassLoader)，由Java语言实现，父类加载器为ExtClassLoader

　　自定义类加载器，父类加载器肯定为AppClassLoader。

032、类的加载过程

1、加载

加载是类加载过程中的一个阶段，不要将这2个概念混淆了。在加载阶段，虚拟机需要完成以下3件事情：

通过一个类的全限定名来获取定义此类的二进制字节流
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

加载.class文件的方式

从本地系统中直接加载
通过网络下载.class文件
从zip，jar等归档文件中加载.class文件
从专有数据库中提取.class文件
将Java源文件动态编译为.class文件

相对于类生命周期的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

2、验证

验证阶段确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

文件格式验证：验证字节流是否符合Class文件格式的规范，如：是否以模数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围内等等。

元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求；如：这个类是否有父类，是否实现了父类的抽象方法，是否重写了父类的final方法，是否继承了被final修饰的类等等。

字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，如：操作数栈的数据类型与指令代码序列能配合工作，保证方法中的类型转换有效等等。

符号引用验证：确保解析动作能正确执行；如：通过符合引用能找到对应的类和方法，符号引用中类、属性、方法的访问性是否能被当前类访问等等。

验证阶段是非常重要的，但不是必须的。可以采用-Xverify:none参数来关闭大部分的类验证措施

3、准备

为类变量分配内存并设置类变量初始值，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

只对static修饰的静态变量进行内存分配、赋默认值（如0、0L、null、false等）。
对final的静态字面值常量直接赋初值（赋初值不是赋默认值，如果不是字面值静态常量，那么会和静态变量一样赋默认值）。

4、解析

将常量池中的符号引用替换为直接引用（内存地址）的过程

符号引用就是一组符号来描述目标，可以是任何字面量。属于编译原理方面的概念如：包括类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。

直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。如指向方法区某个类的一个指针。

假设：一个类有一个静态变量，该静态变量是一个自定义的类型，那么经过解析后，该静态变量将是一个指针，指向该类在方法区的内存地址。

5、初始化

赋初值两种方式：

定义静态变量时指定初始值。如 private static String x="123";
在静态代码块里为静态变量赋值。如 static{ x="123"; }

注意：只有对类的主动使用才会导致类的初始化。

6、使用

7、销毁

033、什么是双亲委派模型，有什么好处？

Java的类加载使用双亲委派模式，即一个类加载器在加载类时，先把这个请求委托给自己的父类加载器去执行，如果父类加载器还存在父类加载器，就继续向上委托，直到顶层的启动类加载器。如果父类加载器能够完成类加载，就成功返回，如果父类加载器无法完成加载，那么子加载器才会尝试自己去加载。

简单总结三个优点：

1、因为双亲委派是向上委托加载的，所以它可以确保类只被加载一次，避免重复加载；

2、Java的核心API都是通过引导类加载器进行加载的，如果别人通过定义同样路径的类比如java.lang.Integer，类加载器通过向上委托，两个Integer，那么最终被加载的应该是jdk的Integer类，而并非我们自定义的，这样就避免了我们恶意篡改核心包的风险；

3、类和他的加载器一起具备了一种带有优先级的层次关系。

034、打破双亲委派模型情况

第一次：

发生在双亲委派模型出现之前，即JDK1.2之前，由于双亲委派模型在JDK1.2之后才被引入，而类加载器和抽象类java.Lang.ClassLoader则在JDK1.0时代就已经存在了，面对已经存在的用户自定义类加载器的实现代码，java设计者引入双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK1.2之后的java.Lang.ClassLoader添加了一个新的protected方法findClass()，在此之前，用户都是去重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass().我们之前也说了loadClass()方法的代码，双亲委派的具体逻辑就实现在这个方法之中，JDK1.2之后已不再提倡用户去覆盖loadClass方法，而是把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里，如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是复合双亲委派模型的。

第二次：

是由这个模型的自身的缺陷导致的，双亲委派能够很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以成为基础，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美，如果基础类又要调用回用户的代码，那该怎么办呢？

那jdk又是怎么做的呢？他们引入了：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.Lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，他将会从父线程中继承一个，如果在应用程序的全局范围都没有设置过的话，那这个类加载器默认就是应用程序类加载器。Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等，这些 SPI 的接口由 Java 核心库来提供，而这些 SPI 的实现代码则是作为 Java 应用所依赖的 jar 包被包含进类路径（CLASSPATH）里。SPI接口中的代码经常需要加载具体的实现类。那么问题来了，SPI的接口是Java核心库的一部分，是由启动类加载器来加载的；SPI的实现类是由系统类加载器来加载的。启动类加载器是无法找到 SPI 的实现类的，因为依照双亲委派模型，BootstrapClassloader无法委派AppClassLoader来加载类。有了线程上下文类加载器，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上已经打破了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则。

第三次：

是由于开发者对程序动态性的追求而导致的，这里说的“动态性”指的是当前一些非常热门的名词，代码热替换、模块热部署等，说白了就是希望应用程序能够像我们的计算机外设那样，接上鼠标、U盘不用重启机器就能使用，鼠标有问题就换个鼠标，不用停机也不用重启。对于个人计算机说来，重启一次其实没有什么，但是对于一些生产系统来说，关机重启一次可能要被列为生产事故，这种情况下热部署就有很大的吸引力。

这里要说到的就是OSGi，先简单了解下什么是OSGi，OSGI（Open Service Gateway Initiative，直译为“开放服务网关”）OSGi联盟给出的最新OSGi定义是The Dynamic Module System for Java，即面向Java的动态模块化系统。

它实现模块化热部署的关键就是它自定义的类加载器机制的实现，每一个程序模块（在OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundlle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。

我们这里简单描述下OSGi收到类加载请求的处理过程

1.将以java.*开头的类委派给父类加载器加载。

2.否则，将委派列表名单内的类委派给父类加载器加载

3.否则将Import列表中得类委派给Export这个类的Bundle的类加载器加载。

4.否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

5.否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给FragmentBundle的类加载器加载。

6.否则，查找Dynamic Import列表的Bundle，委派给对应的Bundle的类加载器加载。

7.否则，类查找失败

上面的查询顺序虽然只有开头两点复合双亲委派模型的规则，其余的类查找都是在平级的类加载器中进行的。

035、类的加载时机

1、new关键字实例化对象

2、读取或设置一个类的静态字段（final修饰除外）

3、调用类的静态方法

4、java.lang.reflect进行反射

5、初始化类的时候，父类未初始化。则需要触发父类的初始化流程。

6、主类（main）

7、接口有默认方法，如果实现类发生初始化，则该接口也需要初始化。

不会被初始化的例子：

1、子类引用父类的静态字段。

2、通过数组定义引用类。

3、final修饰的常量。

036、说一下 JVM 的主要组成部分及其作用？

037、如何查看JVM系统默认值？

jinfo -flag PrintGCDetails 进程号

038、深拷贝和浅拷贝

1、浅拷贝

浅拷贝是按位拷贝对象，它会创建一个新对象，这个对象有着原始对象属性值的一份精确拷贝。如果属性是基本类型，拷贝的就是基本类型的值；如果属性是内存地址（引用类型），拷贝的就是内存地址，因此如果其中一个对象改变了这个地址，就会影响到另一个对象。即默认拷贝构造函数只是对对象进行浅拷贝复制(逐个成员依次拷贝)，即只复制对象空间而不复制资源。

对于基本数据类型的成员对象，因为基础数据类型是值传递的，所以是直接将属性值赋值给新的对象。基础类型的拷贝，其中一个对象修改该值，不会影响另外一个。
对于引用类型，比如数组或者类对象，因为引用类型是引用传递，所以浅拷贝只是把内存地址赋值给了成员变量，它们指向了同一内存空间。改变其中一个，会对另外一个也产生影响。

实现对象拷贝的类，需要实现Cloneable接口，并覆写clone()方法。

2、深拷贝

深拷贝，在拷贝引用类型成员变量时，为引用类型的数据成员另辟了一个独立的内存空间，实现真正内容上的拷贝。

对于基本数据类型的成员对象，因为基础数据类型是值传递的，所以是直接将属性值赋值给新的对象。基础类型的拷贝，其中一个对象修改该值，不会影响另外一个（和浅拷贝一样）。
对于引用类型，比如数组或者类对象，深拷贝会新建一个对象空间，然后拷贝里面的内容，所以它们指向了不同的内存空间。改变其中一个，不会对另外一个也产生影响。
对于有多层对象的，每个对象都需要实现 Cloneable 并重写 clone() 方法，进而实现了对象的串行层层拷贝。
深拷贝相比于浅拷贝速度较慢并且花销较大。

除此之外，还有使用流的方式进行深拷贝。

039、Java中的两种异常类型是什么？他们有什么区别？

一、Throwable是所有异常的根，java.lang.Throwable

Error是错误，java.lang.Error

Exception是异常，java.lang.Exception

二、Exception

一般分为Checked异常和Runtime异常，所有RuntimeException类及其子类的实例被称为Runtime异常，不属于该范畴的异常则被称为CheckedException。

①Checked异常

只有java语言提供了Checked异常，Java认为Checked异常都是可以被处理的异常，所以Java程序必须显示处理Checked异常。如果程序没有处理Checked异常，该程序在编译时就会发生错误无法编译。这体现了Java的设计哲学：没有完善错误处理的代码根本没有机会被执行。对Checked异常处理方法有两种

1 当前方法知道如何处理该异常，则用try...catch块来处理该异常。

2 当前方法不知道如何处理，则在定义该方法是声明抛出该异常。

我们比较熟悉的Checked异常有

Java.lang.ClassNotFoundExceptionJava.lang.NoSuchMetodException

java.io.IOException

②RuntimeException

Runtime如除数是0和数组下标越界等，其产生频繁，处理麻烦，若显示申明或者捕获将会对程序的可读性和运行效率影响很大。所以由系统自动检测并将它们交给缺省的异常处理程序。当然如果你有处理要求也可以显示捕获它们。

我们比较熟悉的RumtimeException类的子类有

Java.lang.ArithmeticException

Java.lang.ArrayStoreExcetpion

Java.lang.ClassCastException

Java.lang.IndexOutOfBoundsException

Java.lang.NullPointerException

三、Error

当程序发生不可控的错误时，通常做法是通知用户并中止程序的执行。与异常不同的是Error及其子类的对象不应被抛出。Error是throwable的子类，代表编译时间和系统错误，用于指示合理的应用程序不应该试图捕获的严重问题。Error由Java虚拟机生成并抛出，包括动态链接失败，虚拟机错误等。程序对其不做处理。

040、简述Java的对象结构

041、对象创建

1、类加载检查

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。new指令对应到语言层面上讲是，new关键词、对象克隆、对象序列化等。

2、分配内存

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

这个步骤有两个问题：

如何划分内存。
在并发情况下，可能出现正在给对象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之中。

在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

5、执行方法

执行方法，即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。

042、什么时候对象会进入老年代？

1、根据对象年龄

JVM会给对象增加一个年龄（age）的计数器，对象每“熬过”一次GC，年龄就要+1，待对象到达设置的阈值（默认为15岁）就会被移移动到老年代，可通过-XX:MaxTenuringThreshold调整这个阈值。

2、动态年龄判断

根据对象年龄有另外一个策略也会让对象进入老年代，不用等待15次GC之后进入老年代，他的大致规则就是，假如当前放对象的Survivor，一批对象的总大小大于这块Survivor内存的50%，那么大于这批对象年龄的对象，就可以直接进入老年代了。

如图上的A、B、D、E这四个对象，假如Survivor 2是100m，如果A + B + D的内存大小超过50m，现在D的年龄是10，那E都会被移动到老年代。实际上这个计算逻辑是这样的：年龄1 + 年龄2 + 年龄n的多个对象总和超过Survivor区的50%，那就会把年龄n以上的对象都放入老年代

3、大对象直接进入老年代

如果设置了-XX:PretenureSizeThreshold这个参数，那么如果你要创建的对象大于这个参数的值，比如分配一个超大的字节数组，此时就直接把这个大对象放入到老年代，不会经过新生代。这么做就可以避免大对象在新生代，屡次躲过GC，还得把他们来复制来复制去的，最后才进入老年代，这么大的对象来回复制，是很耗费时间的。

JVM在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，如果大于，则此次Minor GC是安全的。如果小于，则虚拟机会查看HandlePromotionFailure设置项的值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。

043、Java 中堆和栈有什么区别？

1、各司其职

最主要的区别就是栈内存用来存储局部变量和方法调用。而堆内存用来存储Java中的对象。无论是成员变量，局部变量，还是类变量，它们指向的对象都存储在堆内存中。

2、独有还是共享

栈内存归属于单个线程，每个线程都会有一个栈内存，其存储的变量只能在其所属线程中可见，即栈内存可以理解成线程的私有内存。而堆内存中的对象对所有线程可见。堆内存中的对象可以被所有线程访问。

3、异常错误

如果栈内存没有可用的空间存储方法调用和局部变量，JVM会抛出java.lang.StackOverFlowError。

而如果是堆内存没有可用的空间存储生成的对象，JVM会抛出java.lang.OutOfMemoryError。

4、空间大小

栈的内存要远远小于堆内存，如果你使用递归的话，那么你的栈很快就会充满。如果递归没有及时跳出，很可能发生StackOverFlowError问题。你可以通过-Xss选项设置栈内存的大小。-Xms选项可以设置堆的开始时的大小，-Xmx选项可以设置堆的最大值。

044、垃圾收集底层算法实现

三色标记

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。

这里我们引入“三色标记”来给大家解释下，把Gcroots可达性分析遍历对象过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色：

黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

public class ThreeColorRemark {
    public static void main(String[] args) {
        A a = new A();
        //开始做并发标记
        D d = a.b.d;   // 1.读
        a.b.d = null;  // 2.写
        a.d = d;       // 3.写
    }
}
class A {
    B b = new B();
    D d = null;
}
class B {
    C c = new C();
    D d = new D();
}
class C {
}
class D {
}

多标-浮动垃圾

在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： 增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

增量更新就是当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为， 黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。

原始快照就是当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。所谓的写屏障，其实就是指在赋值操作前后，加入一些处理。

写屏障实现SATB

当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null），我们可以利用写屏障，将B原来成员变量的引用对象D记录下来：

写屏障实现增量更新

当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D记录下来：

读屏障是直接针对第一步：D d = a.b.d，当读取成员变量时，一律记录下来

现代追踪式（可达性分析）的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：比如白色/黑色集合一般都不会出现（但是有其他体现颜色的地方）、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。

对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下：

CMS：写屏障 + 增量更新
G1，Shenandoah：写屏障 + SATB
ZGC：读屏障

工程实现中，读写屏障还有其他功能，比如写屏障可以用于记录跨代/区引用的变化，读屏障可以用于支持移动对象的并发执行等。功能之外，还有性能的考虑，所以对于选择哪种，每款垃圾回收器都有自己的想法。

为什么G1用SATB？CMS用增量更新？

我的理解：SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。

记忆集与卡表

在新生代做GCRoots可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描效率太低了。

为此，在新生代可以引入记录集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个老年代加入GCRoots扫描范围。事实上并不只是新生代、老年代之间才有跨代引用的问题，所有涉及部分区域收集（Partial GC）行为的垃圾收集器，典型的如G1、 ZGC和Shenandoah收集器，都会面临相同的问题。

垃圾收集场景中，收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需了解跨代引用指针的全部细节。

hotspot使用一种叫做“卡表”(Cardtable)的方式实现记忆集，也是目前最常用的一种方式。关于卡表与记忆集的关系，可以类比为Java语言中HashMap与Map的关系。

卡表是使用一个字节数组实现：CARD_TABLE[ ]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡页”。

hotSpot使用的卡页是2^9大小，即512字节

一个卡页中可包含多个对象，只要有一个对象的字段存在跨代指针，其对应的卡表的元素标识就变成1，表示该元素变脏，否则为0.

GC时，只要筛选本收集区的卡表中变脏的元素加入GCRoots里。

卡表的维护

卡表变脏上面已经说了，但是需要知道如何让卡表变脏，即发生引用字段赋值时，如何更新卡表对应的标识为1。

Hotspot使用写屏障维护卡表状态。

045、什么是java对象的指针压缩？

1.jdk1.6 update14开始，在64bit操作系统中，JVM支持指针压缩

2.jvm配置参数:UseCompressedOops，compressed--压缩、oop(ordinary object pointer)--对象指针

3.启用指针压缩:-XX:+UseCompressedOops(默认开启)，禁止指针压缩:-XX:-UseCompressedOops

为什么要进行指针压缩？

1.在64位平台的HotSpot中使用32位指针(实际存储用64位)，内存使用会多出1.5倍左右，使用较大指针在主内存和缓存之间移动数据，占用较大宽带，同时GC也会承受较大压力

2.为了减少64位平台下内存的消耗，启用指针压缩功能

3.在jvm中，32位地址最大支持4G内存(2的32次方)，可以通过对对象指针的存入堆内存时压缩编码、取出到cpu寄存器后解码方式进行优化(对象指针在堆中是32位，在寄存器中是35位，2的35次方=32G)，使得jvm只用32位地址就可以支持更大的内存配置(小于等于32G)

4.堆内存小于4G时，不需要启用指针压缩，jvm会直接去除高32位地址，即使用低虚拟地址空间

5.堆内存大于32G时，压缩指针会失效，会强制使用64位(即8字节)来对java对象寻址，这就会出现1的问题，所以堆内存不要大于32G为好

关于对齐填充：对于大部分处理器，对象以8字节整数倍来对齐填充都是最高效的存取方式。

046、对象栈上分配

我们通过JVM内存分配可以知道JAVA中的对象都是在堆上进行分配，当对象没有被引用的时候，需要依靠GC进行回收内存，如果对象数量较多的时候，会给GC带来较大压力，也间接影响了应用的性能。为了减少临时对象在堆内分配的数量，JVM通过逃逸分析确定该对象不会被外部访问。如果不会逃逸可以将该对象在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。

对象逃逸分析：就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中。

public User test1() {
   User user = new User();
   user.setId(1);
   user.setName("zhuge");
   //TODO 保存到数据库
   return user;
}
public void test2() {
   User user = new User();
   user.setId(1);
   user.setName("zhuge");
   //TODO 保存到数据库
}

很显然test1方法中的user对象被返回了，这个对象的作用域范围不确定，test2方法中的user对象我们可以确定当方法结束这个对象就可以认为是无效对象了，对于这样的对象我们其实可以将其分配在栈内存里，让其在方法结束时跟随栈内存一起被回收掉。

JVM对于这种情况可以通过开启逃逸分析参数(-XX:+DoEscapeAnalysis)来优化对象内存分配位置，使其通过标量替换优先分配在栈上(栈上分配)，JDK7之后默认开启逃逸分析，如果要关闭使用参数(-XX:-DoEscapeAnalysis)

标量替换：通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM不会创建该对象，而是将该对象成员变量分解若干个被这个方法使用的成员变量所代替，这些代替的成员变量在栈帧或寄存器上分配空间，这样就不会因为没有一大块连续空间导致对象内存不够分配。开启标量替换参数(-XX:+EliminateAllocations)，JDK7之后默认开启。

标量与聚合量：标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在JAVA中对象就是可以被进一步分解的聚合量。

/**
 * 栈上分配，标量替换
 * 代码调用了1亿次alloc()，如果是分配到堆上，大概需要1GB以上堆空间，如果堆空间小于该值，必然会触发GC。
 * 
 * 使用如下参数不会发生GC
 * -Xmx15m -Xms15m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
 * 使用如下参数都会发生大量GC
 * -Xmx15m -Xms15m -XX:-DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
 * -Xmx15m -Xms15m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
 */
public class AllotOnStack {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 100000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println(end - start);
    }
    private static void alloc() {
        User user = new User();
        user.setId(1);
        user.setName("zhuge");
    }
}

047、Minor GC、Major GC和Full GC之间的区别

针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种：

Partial GC：并不收集整个GC堆的模式

- Young GC：只收集young gen的GC
- Old GC：只收集old gen的GC。只有CMS的concurrent collection是这个模式
- Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式

Full GC：收集整个堆，包括young gen、old gen、元空间等所有部分的模式。

最简单的分代式GC策略，按HotSpot VM的serial GC的实现来看，触发条件是：并发GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查old gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对old gen做并发收集。

Major GC通常是跟full GC是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是old GC。

young GC：当young gen中的eden区分配满的时候触发。注意young GC中有部分存活对象会晋升到old gen，所以young GC后old gen的占用量通常会有所升高。
full GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（因为HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，所以不需要事先触发一次单独的young GC）；或者元空间已经没有足够空间时，也要触发一次full GC；或者System.gc()、heap dump带GC，默认也是触发full GC。

HotSpot VM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。当然也总有例外。Parallel Scavenge（-XX:+UseParallelGC）框架下，默认是在要触发full GC前先执行一次young GC，并且两次GC之间能让应用程序稍微运行一小下，以期降低full GC的暂停时间（因为young GC会尽量清理了young gen的死对象，减少了full GC的工作量）。控制这个行为的VM参数是-XX:+ScavengeBeforeFullGC。这是HotSpot VM里的奇葩嗯。

048、即时编译器的前后端优化方法

1、方法内联

方法内联编译器最重要的优化手段，业内戏称为“优化之母”。是其他优化手段的基础。

它的行为理解起来其实很简单：就是在方法调用中，把目标方法的代码“复制”到调用的方法之中，避免发生真实的方法调用。

2、逃逸分析

逃逸分析（Escape Analysis）是目前 JVM 中比较前沿的优化技术。但它并不直接优化代码，而是一种为其他优化措施提供依据的分析技术。它的基本原理是分析对象的动态作用域，当一个对象在方法中被定义后，按照逃逸程度从低到高可分为：

不逃逸：对象只能在本方法内使用。
方法逃逸：对象可能被外部方法引用（例如作为调用参数传递到其他方法）。
线程逃逸：对象可能被外部线程访问到（例如赋值给线程共享的变量）。

若一个对象未发生逃逸，或者逃逸程度较低，可以为这个对象采取不同程度的优化。

2.1、栈上分配

JVM 中，对象的内存空间分配在堆上似乎是一个常识。当对象不再使用时，垃圾收集器会将其内存空间回收，这个过程其实是要消耗大量资源的。

假如……把对象的内存空间分配到栈上呢？What ？？？简直是颠覆认知！

但是，不妨沿着这个思路考虑一下：如果这样做了有什么好处呢？

这样一来对象占用的内存空间就会随着栈帧出栈而销毁，不必再由垃圾收集器费时费力地去回收了，可以节省不少资源。这样一想似乎也是不是不可以。

这就是所谓的栈上分配（Stack Allocations），它可以支持「方法逃逸」，但不支持线程逃逸。

PS：由于复杂度等原因，HotSpot 目前暂未做这项优化，但有些 JVM（例如 Excelsior JET）已经在使用了。

2.2、标量替换

先看下标量（Scalar）和聚合量（Aggregate）的概念：

标量：无法再分解为更小数据的数据，例如 JVM 中的原始数据类型（int、long、reference 等）。
聚合量：可以继续分解的数据，例如 Java 中的对象。

所谓「标量替换（Scalar Replacement）」，就是根据实际访问情况，将一个对象“拆解”开，把用到的成员变量恢复为原始类型来访问。

简单来说，就是把聚合量替换为标量。

若一个对象不会逃逸出「方法」，且可以被拆散，那么程序真正执行时就可能不去创建这个对象，而是直接创建它的若干个被该方法使用的成员变量代替。

What ？还有这操作？

其实细想一下，这个操作跟前面的「栈上分配」还是有些类似的：栈上分配的是对象，而标量替换则是在栈上分配对象的一部分成员变量，连对象都懒得创建了。

2.3、同步消除

线程同步本身相对耗时，如果逃逸分析能够确定一个变量不会逃逸出线程，则该变量的读写就不会有线程安全问题，对该变量的同步措施就可以安全的消除了。换句话说，如果对线程安全的数据加了锁，JVM 就可以把它优化消除。示例代码如下：

public void t1() {
    // 变量 o 不会逃逸出线程。因此，对它加的锁就可以被消除
    Object o = new Object();
    synchronized (o) {
        System.out.println(o.toString());
    }
}

3、公共子表达式消除

所谓公共子表达式，就是当有一个表达式 E 在以前被计算过，而且下次再遇到的时候 E 的所有变量都未改变，则这次 E 的出现就被称为「公共子表达式」。也就是不必再花功夫重新计算，直接拿来用就好了。根据作用域，公共子表达式的消除可分为两种：局部公共子表达式消除和全局公共子表达式消除。

public class Test {
    public int t1() {
        int a=1, b=2, c=3;
        int d = (c * b) * 12 + a + (a + b * c);
        return d;
    }
}

public int t2();
    descriptor: ()I
    flags: ACC_PUBLIC
    Code:
      stack=4, locals=5, args_size=1
         # ...
         6: iload_3
         7: iload_2
         8: imul                # 计算 b*c
         9: bipush        12
        11: imul                # 计算 (c * b) * 12
        12: iload_1
        13: iadd                # 计算 (c * b) * 12 + a
        14: iload_1
        15: iload_2
        16: iload_3
        17: imul                # 计算 b*c
        18: iadd                # 计算 (a + b * c)
        19: iadd                # 计算 (c * b) * 12 + a + (a + b * c)
        20: istore        4
        22: iload         4
        24: ireturn
        # ...

Javac 编译器并未做任何优化。这段代码进入即时编译器后，将进行如下优化：编译器检测到 c * b 与 b * c 是一样的表达式，且在计算期间 b 和 c 的值不变，因此：

int d = E * 12 + a + (a + E);

此时，编译器还可能进行代数化简（Algebraic Simplification），如下：

int d = E * 13 + a + a;

这样计算起来就可以节省一些时间。

4、数组边界检查消除

假如有一个数组 array，当我们访问数组下标在 [0, array.length) 范围之外的元素时，就会抛出java.lang.ArrayIndexOutOfBoundsException异常，也就是数组越界了，例如：

public void test1() {
    String[] array = new String[]{"a", "b", "c"};
  // 数组越界
    String s = array[3];
}

其实是 JVM 在执行的时候隐含了一次边界判断（运行期）。当这样的判断很多时，肯定对性能有一定的影响。

但这个判断看起来似乎又是必要的，就不能优化了吗？其实也并非不能，如果把这些判断放在编译期呢？代码在编译的时候，就根据控制流分析是否会产生数组越界，那么在运行期间不是就不用判断了吗？

关注公众号 gosling9527

gosling1024

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
掌握JVM一篇就够了！

001，jvm的运行时数据区不同虚拟机的运行时数据区可能略微有所不同，但都会遵从 Java 虚拟机规范， Java 虚拟机规范规定的区域分为以下 5 个部分：程序计数器（Program Counter Register）：当前线程所执行的字节码的行号指示器，字节码解析器的工作是通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能，都需要依赖这个计数器来完成；Java 虚拟机栈（Java Virtual Machine Stacks）：用于
复制链接

扫一扫

专栏目录