1、JVM的位置

JVM - 图1

2、JVM体系结构

优化也基本在堆和方法区

JVM - 图2

JVM - 图3

3、类加载器

作用:加载 Class文件~ new student()

JVM - 图4

1.虚拟机自带的加载器

2.启动类(根)加载器

3.扩展类加载器

4.应用程序(系统类)加载器

5.双亲委派机制

  1. public class Car {
  2. public static void main(String[] args) {
  3. //类是模板,对象是具体
  4. Car car1 = new Car();
  5. Car car2 = new Car();
  6. Car car3 = new Car();
  7. System.out.println(car1.hashCode());
  8. System.out.println(car2.hashCode());
  9. System.out.println(car3.hashCode());
  10. Class<? extends Car> aClass1 = car1.getClass();
  11. ClassLoader classLoader = aClass1.getClassLoader();
  12. System.out.println(classLoader); //AppClassLoader
  13. System.out.println(classLoader.getParent()); //ExtClassLoader \jre\lib\ext
  14. System.out.println(classLoader.getParent().getParent()); //null 1.不存在 2.Java程序获取不到 rt.jar
  15. }
  16. }

4、双亲委派机制

  1. package java.lang;
  2. //这个类是自己创建的
  3. public class String {
  4. //双亲委派机制:安会
  5. //1.APP-->EXC-B00T(最终执行)
  6. //BOOT
  7. //EXC
  8. //APP
  9. public String toString() {
  10. return "Hello";
  11. }
  12. public static void main(String[] args) {
  13. String s = new String();
  14. System.out.println(s.getClass().getClassLoader());
  15. s.toString()
  16. }
  17. /*
  18. 1.类加载器收到类加载的请求
  19. 2.将这个请求向上委托给父类加载器去完成,一直向上委托,知道启动类加载器
  20. 3.启动加载器检查是否能够加载当前这个类(findClass()),能加载就结束,使用当前的加载器,否则,抛出异常,通知子加载器进行加载
  21. 4.重复步骤 3
  22. CLass not found
  23. nuLL:java调用不到C、C+
  24. Java C++--
  25. */
  26. }

5、沙箱安全机制

  1. java安全模型的核心就是Java沙箱(sandbox),什么是沙箱?沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虛拟机(JVM)特定的运行范围中,并且严格限制代码对本地系统资源访问,通过这样的措施来保证对代码的有效隔离,防止对本地系统造成破坏。沙箱**主要限制系统资源访问**,那系统资源包括什么?CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
  2. 所有的ava程序运行都可以指定沙箱,可以定制安全策略。
  3. Java中将执行程序分成本地代码和远程代码两种,本地代码默认视为可信仼的,而远程代码则被看作是不受信的。对于授信的本地代码,可以访问一切本地资源。而对于非授信的远程代码在早期的ava实现中,安全依赖于沙箱(Sandbox)机制。如下图所示JDK1.0安全模型

JVM - 图5

  1. 但如此严格的安全机制也给程序的功能扩展带来障碍,比如当用户希望远程代码访问本地系统的文件时候,就无法实现。因此在后续的 Java1.1 版本中,针对安全机制做了改进,增加了**安全策略**,允许用户指定代码对本地资源的访问权限。如图 2 所示,

JVM - 图6

  1. Java1.2 版本中,再次改进了安全机制,增加了**代码签名**。不论本地代码或是远程代码,都会按照用户的安全策略设定,由类加载器加载到虚拟机中权限不同的运行空间,来实现差异化的代码执行权限控制。如图 3 所示,

JVM - 图7

  1. 当前最新的安全机制实现,则引入了域 Domain) 的概念。虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责与关键资源进行交互,而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域 (Protected Domain),对应不一样的权限 (Permission)。存在于不同域中的类文件就具有了当前域的全部权限,如图 4 所示 最新的安全模型( jdk1.6):

JVM - 图8

组成沙箱的基本组件:


  • 字节码校验器(bytecode verifier):确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验,比如核心类。

  • 类装载器(class loader):其中类装载器在3个方面对java沙箱起作用

    • 它防止恶意代码去干涉善意的代码 // 双亲委派机制

    • 它守护了被信任的类库边界; // 双亲委派机制

    • 它将代码归入保护域,确定了代码可以进行哪些操作。 // 沙箱安全机制
  1. 虚拟机为不同的类加载器载入的类提供不同的命名空间,命名空间由一系列唯一的名称组成,每一个被装载的类将有一个名字,这个命名空间是由Java虚拟机为每一个类装载器维护的,它们互相之间甚至不可见
  2. 类装载器采用的机制是双亲委派模式。
  1. 从最内层JVM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用
  2. 由于严格通过包来区分了访问域,外层恶意的类通过内置代码也无法获得权限访问到内层类,破坏代码就自然无法生效。
  • 存取控制器(access controller):存取控制器可以控制核心A对操作系统的存取权限,而这个控制的策略设定,可以由用户指定。
  • 安全管理器(security manager):是核心AP和操作系统之间的主要接口。实现权限控制,比存取控制器优先级高。
  • 安全软件包(security package):java.security下的类和扩展包下的类,允许用户为自己的应用增加新的安全特性,包括
    • 安全提供者
    • 消息摘要
    • 数字签名 keytools
    • 加密
    • 鉴别

6、Native

native:凡是带了native关键字的 ,说明Java的作用范围达不到了,会去调用底层C语言的库。

会进入本地方法栈

调用本地方法本地接口JNI

JNI作用:扩展Java的使用,融合不同的编程语言为Java所用!最初:C、C++。

它在内存区域中专门开辟了一块标记区域:Native Method Stack,登记native方法

在最终执行的时候,加载本地方法库中的方法通过JNI

Java程序驱动打印机、管理系统、Robot(),企业级应用较为少见。

调用其他接口:Socket…Webservice…http

Native Method Stack

它的具体做法是Native Method Stack中登记native方法,在(Execution Engine)执行引擎执行的时候加载Native Libraies。【本地库】

7、PC寄存器

程序计数器:Program Counter Register

  1. 每个线程都有一个程序计数器,是线程私有的,就是一个指针,指向方法区中的方法字节码(用来存储指向像一条指令的地址,也即将要执行的指令代码),在执行引擎读取下一条指令,是一个非常小的内存空间,几乎可以忽略不计

8、方法区

Method Anea方法区

  1. 方法区是被所有线程共享,所有字段和方法字节码,以及一些特殊方法,如构造函数,接口代码也在此定义,简单说,所有定义的方法的信息都保存在该区域,**此区域属于共享区间**;
  2. 静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中,但是实例变量存在堆内存中,和方法区无关

static、final、Class、常量池

9、栈

栈:先进后出、后进先出;

队列:先进先出(FIFO:First Input First Output);

喝多了吐就是栈,吃多了拉就是队列

为什么main(先执行,最后结束)

栈:栈内存,主管程序的运行,生命周期和线程同步。

线程结束,栈内存也就是释放,对于栈来说,不存在垃圾回收问题

一旦线程结束,栈就Over

栈:8大基本类型+对象引用(0x 的地址)+实例的方法

栈运行原理:栈帧

栈满了: StackOverflow Error

JVM - 图9

栈 + 堆 + 方法区:交互关系

JVM - 图10

画出一个对象实例化的过程在内存中

对象的实例化、内存布局和访问定位

10、三种JVM

  • Sun公司 HotSpot Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)
  • BEA JRockit
  • IBM J9 VM

11、堆

Heap,一个JVM只有一个堆内存,堆内存的大小是可以调节的。

  1. 类加载器读取了类文件后,一般会把什么东西放到堆中?类、方法、常量、变量。保存所有引用类型的真实对象。

堆内存中还要细分为三个区域

  • 新生区(伊甸园区)Young/New
  • 养老区 old
  • 永久区 Perm

JVM - 图11

GC垃圾回收,主要是在伊甸园区和养老区;

假设内存满了 - OOM,堆内存不够 java.lang.OutofMemoryError: Java heap space

在JDK8以后,永久存储区改了个名字(元空间);

JVM中的新生代和老年代

11.1、新生区

  1. 年轻代主要存放新创建的对象,内存大小相对会比较小,垃圾回收会比较频繁。年轻代分成1Eden Space2Suvivor Space(命名为AB)。当对象在堆创建时,将进入年轻代的Eden Space。垃圾回收器进行垃圾回收时,扫描Eden SpaceA Suvivor Space,如果对象仍然存活,则复制到B Suvivor Space,如果B Suvivor Space已经满,则复制到Old Gen。同时,在扫描Suvivor Space时,如果对象已经经过了几次的扫描仍然存活,JVM认为其为一个持久化对象,则将其移到Old Gen。扫描完毕后,JVMEden SpaceA Suvivor Space清空,然后交换AB的角色(即下次垃圾回收时会扫描Eden SpaceB Suvivor Space。这么做主要是为了减少内存碎片的产生。
  • 类:诞生和成长的地方,甚至死亡;
  • 伊甸园,所有的对象都是在伊甸园区new出来的;
  • 幸存者区(0,1);

真理:经过研究,99%的对象都是临时对象;

11.2、老年区

  1. 年老代主要存放JVM认为生命周期比较长的对象(经过几次的Young Gen的垃圾回收后仍然存在),内存大小相对会比较大,垃圾回收也相对没有那么频繁(譬如可能几个小时一次)。年老代主要采用压缩的方式来避免内存碎片(将存活对象移动到内存片的一边,也就是内存整理)。当然,有些垃圾回收器(譬如CMS垃圾回收器)出于效率的原因,可能会不进行压缩。

11.3、永久区

持久代主要存放类定义、字节码和常量等很少会变更的信息。

  1. 这个区域常驻内存的。用来存放JDK自身携带的Class对象。lnterface元数据,存储的是Java运行时的一些环境或类信息,这个区域不存在垃圾回收。关闭VM虚拟就会释放这个区域的内存。
  2. 一个启动类,加载了大量的第三方jar包。Tomcat部署了太多的应用,大量动态生成的反射类。不断的被加载。直到内存满,就会出现OOM
  • jdk1.6之前:永久代,常量池在方法区
  • jdk1.7 :永久代,但是慢慢的退化了,去永久代,常量池在堆中
  • jdk1.8之后:无永久代,常量池在元空间

JVM - 图12

元空间:逻辑上存在,物理上不存在;

  1. public class Demo {
  2. public static void main(String[] args) {
  3. // 返回虚拟机试图使用的最大内存
  4. long max = Runtime.getRuntime().maxMemory(); // 字节 1024*1024
  5. // 返回jvm的初始化总内存
  6. long total = Runtime.getRuntime().totalMemory();
  7. System.out.println("max=" + max + "字节\t" + (max / (double) 1024 / 1024) + "MB");
  8. System.out.println("total=" + total + "字节\t" + (total / (double)( 1024 * 1024)) + "MB");
  9. // 默认情况下:分配的总内存是电脑内存的1/4,而初始化的内存为1/64
  10. // -Xms1024m -Xmx1024m -XX:+PrintGCDetails
  11. // 314560K + 699072K = 989.875MB
  12. }
  13. }
  1. max=1037959168字节 989.875MB
  2. total=1037959168字节 989.875MB
  3. Heap
  4. par new generation total 314560K, used 22369K [0x00000000c0000000, 0x00000000d5550000, 0x00000000d5550000)
  5. eden space 279616K, 8% used [0x00000000c0000000, 0x00000000c15d8738, 0x00000000d1110000)
  6. from space 34944K, 0% used [0x00000000d1110000, 0x00000000d1110000, 0x00000000d3330000)
  7. to space 34944K, 0% used [0x00000000d3330000, 0x00000000d3330000, 0x00000000d5550000)
  8. concurrent mark-sweep generation total 699072K, used 0K [0x00000000d5550000, 0x0000000100000000, 0x0000000100000000)
  9. Metaspace used 3355K, capacity 4496K, committed 4864K, reserved 1056768K
  10. class space used 354K, capacity 388K, committed 512K, reserved 1048576K

12、堆内存调优

  1. -Xms设置初始化内存分配大小,1/64
  2. -Xmx设置最大分配内存,默认1/4
  3. -XX:+PrintGCDetails //打印GC垃圾回收信息
  4. -XX:+HeapDumpOnOutOfMemoryError //oom DUMP
  5. -Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

12.1、OOM

  1. 尝试扩大推内存看结果
  2. 分析内存,看一下那个地方出现了问题(专业工具)

OOM报错:GC垃圾回收

  1. // -Xms8m -Xmx8m -XX:+PrintGCDetails
  2. public class Hello {
  3. public static void main(String[] args) {
  4. String s = "6b92d6";
  5. while (true) {
  6. s += s + new Random().nextInt(888888888) + new Random().nextInt(999999999);
  7. }
  8. }
  9. }
  1. [GC (Allocation Failure) [ParNew: 2171K->255K(2432K), 0.0016619 secs] 2171K->744K(7936K), 0.1032077 secs] [Times: user=0.00 sys=0.00, real=0.10 secs]
  2. [GC (Allocation Failure) [ParNew: 2046K->118K(2432K), 0.0007043 secs] 2535K->1341K(7936K), 0.0007318 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  3. [GC (Allocation Failure) [ParNew: 1709K->34K(2432K), 0.0004728 secs] 2932K->2025K(7936K), 0.0004931 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  4. [GC (Allocation Failure) [ParNew: 850K->14K(2432K), 0.0005070 secs] 2840K->2771K(7936K), 0.0005343 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  5. [GC (CMS Initial Mark) [1 CMS-initial-mark: 2757K(5504K)] 4316K(7936K), 0.0001107 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  6. [CMS-concurrent-mark-start]
  7. [GC (Allocation Failure) [ParNew: 1559K->16K(2432K), 0.0008168 secs] 4316K->4308K(7936K), 0.0008370 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  8. [GC (Allocation Failure) [ParNew: 1596K->1596K(2432K), 0.0000139 secs][CMS[CMS-concurrent-mark: 0.001/0.014 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
  9. (concurrent mode failure): 4292K->2122K(5504K), 0.0399732 secs] 5888K->2122K(7936K), [Metaspace: 3341K->3341K(1056768K)], 0.0403072 secs] [Times: user=0.00 sys=0.00, real=0.04 secs]
  10. [GC (Allocation Failure) [ParNew: 1599K->1599K(2432K), 0.0000170 secs][CMS: 5192K->4442K(5504K), 0.0032203 secs] 6791K->4442K(7936K), [Metaspace: 3345K->3345K(1056768K)], 0.0032817 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  11. [GC (CMS Initial Mark) [1 CMS-initial-mark: 4442K(5504K)] 5977K(7936K), 0.0001539 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  12. [CMS-concurrent-mark-start]
  13. [GC (Allocation Failure) [ParNew (promotion failed): 1576K->1578K(2432K), 0.0002551 secs][CMS[CMS-concurrent-mark: 0.001/0.014 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
  14. (concurrent mode failure): 4444K->2140K(5504K), 0.0160909 secs] 6018K->2140K(7936K), [Metaspace: 3345K->3345K(1056768K)], 0.0163817 secs] [Times: user=0.00 sys=0.00, real=0.02 secs]
  15. [GC (Allocation Failure) [ParNew: 1579K->1579K(2432K), 0.0000117 secs][CMS: 5210K->5192K(5504K), 0.0028039 secs] 6789K->5192K(7936K), [Metaspace: 3346K->3346K(1056768K)], 0.0028512 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  16. [Full GC (Allocation Failure) [CMS: 5192K->5172K(5504K), 0.0022938 secs] 5192K->5172K(7936K), [Metaspace: 3346K->3346K(1056768K)], 0.0023135 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  17. [GC (CMS Initial Mark) [1 CMS-initial-mark: 5172K(5504K)] 5214K(7936K), 0.0001630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  18. [CMS-concurrent-mark-start]
  19. [CMS-concurrent-mark: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  20. [CMS-concurrent-preclean-start]
  21. [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  22. [GC (CMS Final Remark) [YG occupancy: 42 K (2432 K)][Rescan (parallel) , 0.0001410 secs][weak refs processing, 0.0000060 secs][class unloading, 0.0002987 secs][scrub symbol table, 0.0004870 secs][scrub string table, 0.0001310 secs][1 CMS-remark: 5172K(5504K)] 5214K(7936K), 0.0011202 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  23. [CMS-concurrent-sweep-start]
  24. [CMS-concurrent-sweep: 0.000/0.000 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
  25. [CMS-concurrent-reset-start]
  26. [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  27. Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
  28. at java.util.Arrays.copyOf(Arrays.java:3332)
  29. at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
  30. at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
  31. at java.lang.StringBuilder.append(StringBuilder.java:208)
  32. at cn.dafran.Hello.main(Hello.java:17)
  33. Heap
  34. par new generation total 2432K, used 127K [0x00000000ff800000, 0x00000000ffaa0000, 0x00000000ffaa0000)
  35. eden space 2176K, 5% used [0x00000000ff800000, 0x00000000ff81fef8, 0x00000000ffa20000)
  36. from space 256K, 0% used [0x00000000ffa20000, 0x00000000ffa20000, 0x00000000ffa60000)
  37. to space 256K, 0% used [0x00000000ffa60000, 0x00000000ffa60000, 0x00000000ffaa0000)
  38. concurrent mark-sweep generation total 5504K, used 566K [0x00000000ffaa0000, 0x0000000100000000, 0x0000000100000000)
  39. Metaspace used 3407K, capacity 4496K, committed 4864K, reserved 1056768K
  40. class space used 362K, capacity 388K, committed 512K, reserved 1048576K

在一个项目中,突然出现了OOM故障,那么该如何排除~研究为什么出错

  • 能够看到代码第几行出错:内存快照分析工具,MAT、Jprofiler
  • Debug,一行行分析代码

MAT、Jprofiler作用

  • 分析Dump内存文件,快速定位内存泄露
  • 获得堆中的数据
  • 获得大的对象
  • ……

12.2、Jprofiler

Jprofiler

  1. // Dump
  2. // -Xms设置初始化内存分配大小,1/64
  3. // -Xmx设置最大分配内存,默认1/4
  4. // -XX:+PrintGCDetails //打印GC垃圾回收信息
  5. // -XX:+HeapDumpOnOutOfMemoryError //oom DUMP
  6. // -Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
  7. public class Dafran {
  8. byte[] array = new byte[1*1024*1024]; // 1m
  9. public static void main(String[] args) {
  10. ArrayList<Dafran> list = new ArrayList<>();
  11. int count = 0;
  12. try {
  13. while (true) {
  14. list.add(new Dafran());
  15. count++;
  16. }
  17. } catch (Error e) {
  18. System.out.println("count:"+count);
  19. e.printStackTrace();
  20. }
  21. // Throwable
  22. // Exception
  23. // error
  24. }
  25. }

13、GC:垃圾回收

JVM - 图13

JVM在进行GC时,并不是对这三个区域统一回收。大部分时候,回收都是新生代~

  • 新生代
  • 幸存区(form,to)
  • 老年代

GC两种类:

  • 轻GC(普通的GC)
  • 重GC(全局GC)

GC题目:

  • JVM的内存模型和分区~详细到每个区放什么?
  • 堆里面的分区有哪些?(Eden、form、to、老年区),说说它们的特点。
  • GC的算法有哪些?标记清除法,标记压缩,复制算法,引用计数,怎么用的?
  • 轻GC和重GC分别在什么时候发生?

13.1、GC常用算法

13.1.1、引用计数法

JVM - 图14

GC-引用计数法

13.1.2、复制算法

JVM - 图15

JVM - 图16

  • 好处:没有内存的碎片
  • 坏处:浪费了内存空间~:多了一半空间永远是空To。假设对象100%存活(极端情况)

复制算法最佳使用场景:对象存活度较低的时候;

GC-复制算法

GC-对象进入老年代的条件

  1. 控制参数详解:
  2. -XX:MaxTenuringThreshold = 15 # 默认值
  3. -Xms设置堆的最小空间大小。
  4. -Xmx设置堆的最大空间大小。
  5. -Xmn堆中新生代初始及最大大小(NewSizeMaxNewSize为其细化)。
  6. -XX:NewSize设置新生代最小空间大小。
  7. -XX:MaxNewSize设置新生代最大空间大小。
  8. -XX:PermSize设置永久代最小空间大小。
  9. -XX:MaxPermSize设置永久代最大空间大小。
  10. -Xss设置每个线程的堆栈大小。

13.1.3、标记清除算法

JVM - 图17

  • 优点:不需要额外的空间。
  • 缺点:两次扫描,严重浪费时间,会产生内存碎片。

GC标记-清除算法(Mark Sweep GC)

标记压缩

再优化:

JVM - 图18

标记清除压缩

先标记清除多次

JVM - 图19

再进行压缩

JVM - 图20

标记清除算法和标记压缩算法

13.2、总结

内存效率:复制算法>标记清除算法>标记压缩算法(时间复杂度)

内存整齐度:复制算法=标记压缩算法>标记清除算法

内存利用率:标记压缩算法=标记清除算法>复制算法

垃圾回收的三种算法

没有最好的算法,只有最合适的算法 —— GC分代收集算法

年轻代:

  • 存活率低
  • 复制算法

老年代:


  • 区域大:存活率高

  • 标记清除(内存碎片不是太多)+ 标记压缩混合实现

GC算法精解(分代搜集算法)

14、JMM

JMM是什么

  1. JMM】(Java Memory Model的缩写)—— Java内存模型

JMM的作用

  1. **缓存一致性协议,用于定义数据读写的规则(遵守,找到这个规则)。**
  2. 从抽象的角度来看,JMM定义了线程工作内存和主内存之间的抽象关系:线程之间的共享变量存储在主内存(Main Memory)中,每个线程都有一个私有的本地内存(LocalMemory)。

JVM - 图21

解决共享对象可见性这个问题:volilate

Java并发编程:volatile关键字

如何学习?

JMM:抽象的概念,理论

JMM对这八种指令的使用,制定了如下规则:

  • 不允许read和load、store和write操作之一单独出现。即使用了read必须load,使用了store必须write
  • 不允许线程丢弃他最近的assign操作,即工作变量的数据改变了之后,必须告知主存
  • 不允许一个线程将没有assign的数据从工作内存同步回主内存
  • 一个新的变量必须在主内存中诞生,不允许工作内存直接使用一个未被初始化的变量。就是烈变量实

施use、store操作之前,必须经过assign和load操作

  • 一个变量同一时间只有一个线程能对其进行lock。多次lock后,必须执行相同次数的unlock才能解锁
  • 如果对一个变量进行lock操作,会清空所有工作内存中此变量的值,在执行引擎使用这个变量前,必

须重新load或assign操作初始化变量的值

  • 如果一个变量没有被lock,就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
  • 对一个变量进行unlock操作之前,必须把此变量同步回主内存

    JMM对这八种操作规则和对volatile的一些特殊规则就能确定哪里操作是线程安全,哪些操作是线程不安全的了。但是这些规则实在复杂,很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候,使用java的happen-before规则来进行分析。

深入理解Java内存模型JMM