一、JVM

1、JVM虚拟机基于栈的结构，相比于寄存器结构指令集空间小，但是执行一个操作的指令数比较多，效率比较差

2、Classic,没有即时编译器(JIT)->HotSpot(sun，包含JIT，在响应时间和性能方面取平衡、方法区、元空间)->JRockit(BEA，不包含JIT)->J9(IBM)

3、即时编译器(JIT) -热点代码探测技术 ，如果全用JIT，效率会变差

4、JVM并不是把所有的类一次性全部加载到JVM中的，java虚拟机对class文件采取的是按需加载的方式，也不是每次用到一个类的时候都去查找，对于JVM级别的类加载器在启动时就会把默认的JAVA_HOME/lib里的class文件加载到JVM中，因为这些是系统常用的类，并初始化sun.misc.Launcher从而创建Extension ClassLoader和Application ClassLoader的实例。其他类使用到该类才会加载到内存中生成class对象，所以就需要双亲委派机制。

1
2
3
4
5

public class Test {
    public static void main(String[] args) {
        String a = "sd";
    }
}

当前类Test是一个用户自定义的加载器，所以加载这个类就要用到系统类加载器，然后加载到里面的String类的时候，当前系统类加载器会交给上级加载，所以就用引导类加载器加载了。类里面的使用的其他类，会用加载当前类的类加载器去加载。

5、执行引擎=解释器+JIT即时编译器+垃圾回收

6、程序计数器：存储当前线程该执行的指令地址

7、类加载过程中的链接过程里面的Resolution（解析）：将常量池中的符号引用解析为直接引用，这时应该只能处理一些简单的能确定的引用，而向多态这种运行时才知道实际引用的情况，应该用的是虚拟机栈的动态链接

8、启动HotSpot Debugger [HSDB] 查看虚拟机内存状态

1

java -cp ./sa-jdi.jar sun.jvm.hotspot.HSDB

9、Error和GC

二、栈

1、分配的栈内存越大越好吗？

内存越多，会让stackoverflowerror延后出现，但是不会避免，还会挤占其他线程的空间

2、方法中定义的局部变量是否线程安全？

具体问题具体分析；

何为线程安全？如果只有一个线程操作此数据，则线程安全；如果数据被多个线程共享，则不安全

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

public class Test{
  
  public static void method1(){
    //stringbuilder 是线程不安全的类
    //但是这个s1变量是线程安全的，因为只有一个线程访问
    StringBuilder s1 = new StringBuilder();
    s1.append("a");
    s1.append("b");
    //...
    
  }
  
  //s2的操作过程是线程不安全的
  public static void method2(StringBuilder s2){
    s2.append("a");
    s2.append("b");
    //...
  }
  
  //s3的操作过程有可能线程不安全,因为返回值有可能被其他线程抢用
  public static StringBuilder method3(){
    StringBuilder s3 = new StringBuilder();
    s3.append("a");
    s3.append("b");
    return s3;
  }
  
  
  public static void main(String[] args){
    
    StringBuilder s = new StringBuilder();
    new Thread(()->{
      s.append("a");
    	s.append("b");
    }).start();
    //线程不安全
    method2(s);
    
  }
  
}

二、堆和垃圾回收

1、new的对象先放伊甸园区。此区有大小限制。

2、当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（MinorGC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区

3、然后将伊甸园中的剩余对象移动到幸存者0区。

4、如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。

5、如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。

6、啥时候能去养老区呢？可以设置次数。默认是15次。

• • 可以设置参数：进行设置-Xx:MaxTenuringThreshold= N

7、在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理

8、若养老区执行了Major GC之后，发现依然无法进行对象的保存，就会产生OOM异常。

1、设置堆空间大小 -Xms -Xmx

默认：起始堆空间大小为计算机物理内存的64分之一，最大堆空间大小为计算机物理内存的4分之一

开发中建议初始堆内存和最大堆内存设置为一样的数值，减少频繁的扩容和释放，造成系统压力

1
2

Runtime.getRuntime().maxMemory();
获取最大堆内存，发现比 -Xmx中设置的值少了一部分，是因为伊甸园区的s0 s1 区域只能使用一个

堆空间大小，无论是默认的还是自己设置的，都不包括 永久代(JDK7) 和 元空间(JDK8)

2、设置老年代和新生代的比例：-XX:NewRatio=2 ，默认值为2

设置新生代中eden和survivor比例：默认为8:1:1，但是默认情况下启动应用，用jvisualVM发现比例是6:1:1，这是因为jvm做了内存的自适应，如果要确切用8:1:1，则需显示的配置jvm参数： -XX:SurvivorRatio=8

几乎所有对象都是在Eden区被new出来的

绝大部分java对象的销毁都在新生代进行

-Xmn 可以设置新生代最大内存大小，和-XX:NewRatio=2冲突时，以-Xmn为准

3、YGC==minorGC，当Eden区满的时候会触发YGC/minorGC，回收Eden区和survivor中的From区中的垃圾；但是当某个survivor满的时候是不会触发YGC/minorGC，这种情况有可能直接复制到老年代。

survivor区中的from和to区，谁空谁是to

4、垃圾回收经验：

YGC之后 伊甸园区一定是空的；

OOM几乎都发生在老年代中；

新生代频繁回收，老年代很少回收，几乎不在永久代回收

5、垃圾回收是有一个GC线程的，和用户线程分开

6. Minor GC，MajorGC、Full GC

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。

针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）

• 部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：

• • 新生代收集（Minor GC / Young GC）：只是新生代(Eden\s0\s1)的垃圾收集
• • 老年代收集（Major GC / Old GC）：只是老年代的圾收集。
• • • 目前，只有CMSGC会有单独收集老年代的行为。
• • • 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
• • 混合收集（MixedGC）：收集整个新生代以及部分老年代的垃圾收集。
• • • 目前，只有G1 GC会有这种行为

• 整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。 新生代+老年代+方法区(永久代/元空间)

年轻代

• 当年轻代空间不足时，就会触发MinorGC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC。（每次Minor GC会清理年轻代的内存。）

• 因为Java对象大多都具备朝生夕灭的特性.，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。

• Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行

老年代GC（Major GC / Full GC）触发机制

• 指发生在老年代的GC，对象从老年代消失时，我们说 “Major GC” 或 “Full GC” 发生了

• 出现了Major Gc，经常会伴随至少一次的Minor GC（但非绝对的，在Paralle1 Scavenge收集器的收集策略里就有直接进行MajorGC的策略选择过程）

  • 也就是在老年代空间不足时，会先尝试触发Minor Gc。如果之后空间还不足，则触发Major GC
  • 并发GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查old gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对old gen做并发收集。

• Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长

• 如果Major GC后，内存还不足，就报OOM了

Full GC触发机制：

触发Full GC执行的情况有如下五种：

• 调用System.gc()时，系统建议执行Full GC，但是不必然执行

• 老年代空间不足

• 方法区空间不足

• 通过Minor GC后进入老年代的平均大小大于老年代的可用内存，空间分配担保

• 由Eden区、survivor space0（From Space）区向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

说明：Full GC 是开发或调优中尽量要避免的。这样暂时时间会短一些

7、方法区的实现

8以前叫永久代，8叫元空间

8、显示堆空间信息

-XX:+PrintGCDetails

9、为什么要把Java堆分代？不分代就不能正常工作了吗？

经研究，不同对象的生命周期不同。70%-99%的对象是临时对象。

• 新生代：有Eden、两块大小相同的survivor（又称为from/to，s0/s1）构成，to总为空。

• 老年代：存放新生代中经历多次GC仍然存活的对象。

其实不分代完全可以，分代的唯一理由就是优化GC性能。如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

10、内存分配策略

如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到survivor空间中，并将对象年龄设为1。对象在survivor区中每熬过一次MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代

对象晋升老年代的年龄阀值，可以通过选项-XX:MaxTenuringThreshold来设置

针对不同年龄段的对象分配原则如下所示：

• 优先分配到Eden

• 大对象直接分配到老年代（尽量避免在开发中出现过多的大对象）

• 长期存活的对象分配到老年代

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

• 真实情况：年龄1+年龄2+年龄3+年龄N的对象加起来的空间，大于survivor区域的一半，就会让年龄N和年龄N以上的对象进入老年代。动态年龄判断应该是这样子的。说的通俗一点：就是年龄从小到大对象的占据空间的累加和，而不是某一个特定年龄对象占据的空间。-XX:TargetSurvivorRatio 设置目标存活率，默认为50%，年龄从小到大进行累加，当加入某个年龄段后，累加和超过survivor区域*TargetSurvivorRatio的时候，就从这个年龄段网上的年龄的对象进行晋升

• 空间分配担保： -XX:HandlePromotionFailure

11、TLAB的再说明

• 尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选。

• 在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。

• hotSpot虚拟机默认开启TLAB

• 默认情况下，TLAB空间的内存非常小，仅占有整个Eden空间的1%，当然我们可以通过选项 -XX:TLABWasteTargetPercent设置TLAB空间所占用Eden空间的百分比大小。

• 一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存。