(狂神)狂神-JVM入门
1、前言#
1.1 浅谈jvm面试题#
- 请你谈谈你对JVM的理解? java8虚拟机和之前的变化更新?
- 什么是00M,什么是栈溢出StackOverFlowError?怎么分析?
- JVM的常用调优参数有哪些?
- 内存快照如何抓取,怎么分析Dump文件?知道吗?
- 谈谈JVM中,类加载器你的认识?
-
JDK>jre>jvm(包含)
-
jvm使用c语言写的
-
java也叫C+±-?
-
java去掉了C++繁琐的东西,指针,内存管理
-
栈内不可能会有垃圾回收。为什么?
-
栈用完就会弹出去,不弹出去下一个无法读取运行,有垃圾程序堵死。
-
方法区属于一个特殊的堆。jvm调优主要是在堆里,
-
所以jvm调优99%的情况都是在调方法区和堆区
-
java创建对象,堆内存放实例,栈内存放地址。栈内地址映射着堆内的实例对象。所以栈内没什么垃圾,垃圾在堆内。
-
类是模板,是抽象的;对象是具体的
2、JVM体系结构#
2.1、JVM的位置#
2.2、JVM的体系结构#
网络样图
java虚拟机运行时数据区
-
方法区:
- 方法区存储虚拟机加载的类信息、常量、静态变量、即使编译器翻译后的代码等数据;
- 是JVM规范中的一部分,并不是实际的实现,在实际实现上并不相同(HotSpot在1.7版本以前和1.7版本,1.7后都有变化)。
- 当方法区无法满足内存分配需求时,将抛出OutOfMemoryError(OOM)异常
-
java堆:
- 仅有一个堆,Java堆用于存放new出来的对象的内容。
- 是垃圾收集器管理的主要区域。可细分为:新生代和老生代;新生代又可分为Eden、from Survivor, to Survivor。
- 如果在堆中 没有内存完成实例分配, 并且堆也无法再扩展时,将会抛出 OutOfMemoryError 异常。
-
Java虚拟机栈:
- 存放的东西:八大基本类型 + new出来的对象引用地址 + 实例方法的引用地址。
- 每一条 java虚拟机线程都有自己私有的java虚拟机栈,这个 栈和线程同时创建, 用于存储 栈帧。
- Java虚拟机栈是 Java方法执行的内存模型,每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
- 栈帧(Stack Frame) 存储局部变量表,操作数据栈,动态链接,方法出口等信息,随着方法的调用而创建,随着方法的结束而销毁。
- 在Java虚拟机规范中,对这个区域规定了两种异常状况:
- 如果 线程请求的栈深度 大于 虚拟机所允许的深度,将抛出StackOverflowError异常;
- 如果虚拟机栈可以动态扩展(当前大部分的Java虚拟机都可动态扩展,只不过Java虚拟机规范中也允许固定长度的虚拟机栈),当扩展时无法申请到足够的内存时,会抛出utOfMemoryError异常。
-
本地方法栈:
- 本地方法栈和虚拟机栈非常相似,不同的是 虚拟机栈服务的是【Java方法】,而 本地方法栈服务的是【Native方法】
- HotSpot虚拟机 直接把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowError 和 OutOfMemoryError 异常。
-
程序计数器:
- java虚拟机可以支持多个线程同时运行,每个java虚拟机线程都有自己的程序计数器(PC寄存器)。
- 在任意时刻,一个java虚拟机的线程,只会执行一个方法的代码。
- 程序计数器记录 【当前线程所执行的Java字节码的地址】。
- 当执行的是Native方法时,程序计数器为空。 程序计数器是JVM规范中唯一一个没有规定会导致OOM(OutOfMemory)的区域。
3、类加载的过程#
3.1 概述#
运行顺序
- java源代码文件会被java编译器译为字节码文件(.class后缀)。
- 然后由JVM中的类加载器加载各个类的字节码文件。
- 加载完毕后,交由JVM执行引擎执行。
垃圾和调优
99%的JVM调优都是在堆中调优,java栈,本地方法栈,程序计数器是不会有垃圾存在的。
3.2、流程#
其中 加载、验证、准备、初始化、卸载这五个阶段的过程是固定的,在类加载过程中必须按照这种顺序按部就班的进行,而解析阶段就不一样了,可以在初始化后进行,是为了支持java语言的运行时绑定。
加载
- 通过一个类的权限定名获取定义此类的二进制字节流;
- 将这个字节流所代表的的静态存储结构转换为方法区的运行时数据结构;
- 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据结构的访问入口;
加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中,而且在java堆中也创建一个java.lang.Class类的对象,这样便可以通过该对象访问方法区中的这些数据。
验证
这一阶段主要是为了确保Class文件的字节流中包含的信息符合虚拟机的要求,并且不会危害虚拟机自身的安全。
四个校验动作:
- 文件格式验证:验证字节流是否符合Class文件格式的规范。
- 元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求。
- 字节码验证:通过数据流和控制流分析。确定程序语义是合法的、符合逻辑的。
- 符号引用验证:确保解析动作能正确执行。
准备
是正式为类变量分配内存并设置初始值的阶段,这些变量所使用的的内存都将在方法区分配。
进行内存分配的仅包括类变量(static),而不包括实例变量,实例变量会在对象实例化时随着对象一块分配在java堆中,初始值通常情况下是数据类型默认的零值。
解析
是将虚拟机常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定附。
符号引用:与虚拟机实现的布局无关,引用的目标并不一定要已经加载到内存中。虚拟机能接收的符号引用必须是一致的,因为符号引用的字面量形式明确定义在java虚拟机规范的Class文件格式中。
直接引用:可以是指向目标的指针,相对偏移量或者是一个能间接定位到目标的句柄,如果有了直接引用那么引用目标必定已经在内存中存在。
初始化
类初始化时类加载的最后一步,处理加载阶段,用户可以通过自定义的类加载器参数,其他阶段都完全由虚拟机主导和控制。到了初始化阶段才真正执行Java代码。
类的初始化的主要工作是为了静态变量赋程序设定的初始值
static int a=100; 在准备阶段a被赋默认值0,在初始化阶段就会被赋值为100
java虚拟机规范中严格规定了有且只有五种情况必须对类进行初始化:
-
使用new创建类的实例,或者使用getstatic、putstatic读取或设置一个静态字段的值(放入常量池中的常量除外),或者调用一个静态方法的时候,对应类必须进行初始化。
-
通过java.lang.reflect包的方法对类进行反射调用的时候,要是类没有进行过初始化,则要首先进行初始化。
-
当初始化一个类的时候,如果发现其父类没有进行过初始化,则首先触发父类初始化。
-
当虚拟机启动时,用户需要指定一个主类(包含main()方法的类),虚拟机会首先初始化这个类。
-
使用jdk1.7的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、RE_invokeStatic的方法句柄,并且这个方法句柄对应的类没有进行初始化,则需要先触发其初始化。
4、类加载器#
作用:加载.class文件
新建的对象放入堆中,引用(地址)放到栈,其中引用指向堆里边对应的对象。
- 先来看看一个类加载到 JVM 的一个基本结构:
- 类是模板,对象是具体的,通过new来实例化对象。car1,car2,car3,名字在栈里面,真正的实例,具体的数据在堆里面,栈只是引用地址。
- 虚拟机自带的加载器
- 启动类(根)加载器 Bootstrap ClassLoader
- 扩展类加载器 Extension ClassLoader
- 应用程序(系统类)加载器 Application ClassLoader
Car car = new Car();
Class<? extends Car > aClass = car.getClass();
ClassLoader classLoader = aClass.getClassLoader(); // Application 加载器
classLoader.getParent(); // ExtClassLoader 扩展类加载器
classLoader.getParent().getParent(); // null 1.不存在 2. java 获取不到(可能是c++写的)
类加载器的分类
- Bootstrap ClassLoader 启动类加载器-------->负责加载jre\lib目录下的rt.jar
- Extention ClassLoader 标准扩展类加载器-------->负责加载jre\lib\ext目录下的所有jar包
- Application ClassLoader 应用类加载器-------->负责加载用户类路径上所指定的类库,如果应用程序中没有自定义加载器,那么此加载器就为默认加载器。
- User ClassLoader 用户自定义类加载器
5、双亲委派机制#
5.1 举例#
package java.lang;
public class String {
/*
双亲委派机制:安全
1.APP-->EXC-->BOOT(最终执行)
BOOT
EXC
APP
*/
public String toString() {
return "Hello";
}
// 报错:找不到sting类中的main方法
public static void main(String[] args) {
String s = new String();
System.out.println(s.getClass());
s.toString();
}
/*
1.类加载器收到类加载的请求
2.将这个请求向上委托给父类加载器去完成,一直向上委托,直到启动类加载
3.启动加载器检查是否能够加载当前这个类,能加载就结束,使用当前的加载器,否则,抛出异常,通知子加载器进行加载
4.重复步骤3
*/
}
- idea报了一个错误:
- 执行过程:这是因为,在运行一个类之前,首先会在应用程序加载器(APP)中找,继续向上在扩展类加载器EXC中找,然后再向上,在启动类( 根 )加载器BOOT中找。如果在BOOT中有这个类的话,最终执行的就是根加载器中的。如果BOOT中没有的话,就会倒找往回找。
过程总结
1、类加载器收到类加载的请求;
2、将这个请求向上委托给父类加载器去完成,一直向上委托,直到启动类加载器;
3、启动类加载器检查是否能够加载当前这个类,能加载就结束,使用当前的加载器。不能加载就会抛出异常,一层一层向下,通知子加载器进行加载。
4、重复步骤3
5.2 作用#
概念
当某个类加载器需要加载某个.class文件时,它首先把这个任务委托给他们的上级类加载器,递归这个操作,如果上级类加载器没有加载,自己才会去加载这个类。
例子
当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器,首先会在AppClassLoader中检查是否加载过,如果有那就无需再加载了。如果没有,那么会拿到父加载器,然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过,如果没有再往上。注意这个类似递归的过程,直到到达Bootstrap classLoader之前,都是在检查是否加载过,并不会选择自己去加载。直到BootstrapClassLoader,已经没有父加载器了,这时候开始考虑自己是否能加载了,如果自己无法加载,会下沉到子加载器去加载,一直到最底层,如果没有任何加载器能加载,就会抛出ClassNotFoundException。
作用
1、为了防止重复加载同一个.class。通过委托去向上面问一问,加载过了,就不用再加载一遍了。保证数据的安全。
2、保证核心.class不能被篡改。通过委托方式,不会去篡改核心.class,即使篡改了也不会去加载,即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样就保证了Class的安全执行。
6、沙箱安全机制#
6.1 概述#
Java安全模式的核心就是Java沙箱(sandbox)
什么是沙箱
沙箱是一个限制程序运行的环境。沙箱机制就是 将Java代码限定在虚拟机(JVM)特定的运行范围中,并且严格限制代码对本地系统资源的访问。
通过这样的措施来保证对代码的有效隔离,防止对本地系统造成破坏。
沙箱主要限制系统资源访问,那系统资源包括什么?
CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
所有的Java程序运行都可以指定沙箱,可以定制安全策略。
6.2 历史#
在Java中将执行的程序分成本地代码和远程代码两种。
- 本地代码默认为可信任的,而远程代码则被看做是不受信任的。对于授信的本地代码,可以访问一切本地资源。
- 而对于非授信的远程代码在早期的Java实现中,安全依赖于沙箱 Sandbox 机制。如下图所示JDK1.0安全模型
- 但如此严格的安全机制也给程序的功能扩展带来障碍,比如当用户希望远程代码访问本地系统的文件时候,就无法实现。
- 因此在后续的Java1.1版本中,针对安全机制做了改进,增加了安全策略,允许用户指定代码对本地资源的访问权限。
- 在Java1.2版本中,再次改进了安全机制,增加了代码签名。
- 不论本地代码或是远程代码,都会按照用户的安全策略设定,
- 由类加载器加载到虚拟机中权限不同的运行空间,来实现差异化的代码执行权限控制。
-
当前最新的安全机制实现,则引入了 域(Domain) 的概念。
-
虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责域关键资源进行交互,而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。
-
虚拟机中不同的受保护域(Protected Domain),对应不一样的权限(Permission)。
-
存在于不同域中的类文件就具有了当前域的全部权限,
下图所示为最新的安全模型(jdk 1.6)
6.3 组成沙箱的基本组件#
-
字节码校验器(bytecode verifier) :
- 确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。
- 但并不是所有的类文件都会经过字节码校验,比如核心类。如:new String();
-
类裝载器(class loader) :
- 其中类装载器在3个方面对Java沙箱起作用
- 它防止恶意代码去干涉善意的代码;
- 它守护了被信任的类库边界;
- 它将代码归入保护域,确定了代码可以进行哪些操作。
- 虚拟机为不同的类加载器载入的类提供不同的命名空间。
- 命名空间由一系列唯一的名称组成, 每一个被装载的类将有一个名字,
- 这个命名空间是由Java虚拟机为每一个类装载器维护的,它们互相之间甚至不可见。
- 类装载器采用的机制是双亲委派模式。
- 1.从最内层JVM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用;
- 2.由于严格通过包来区分了访问域,外层恶意的类通过内置代码也无法获得权限访问到内层类,破坏代码就自然无法生效。
- 存取控制器(access controller) :存取控制器可以控制核心API对操作系统的存取权限,而这个控制的策略设定,可以由用户指定。
- 安全管理器(security manager) : 是核心API和操作系统之间的主要接口。实现权限控制,比存取控制器优先级高。
- 安全软件包(security package) : java.security下的类和扩展包下的类,允许用户为自己的应用增加新的安全特性,包括:
- 安全提供者
- 消息摘要
- 数字签名
- 加密
- 鉴别
- 其中类装载器在3个方面对Java沙箱起作用
7、Native、本地方法栈#
71. 概述#
-
Native:凡是带了native关键字的,说明java的作用范围达不到了,会去调用底层C语言的库; --》会进入本地方法栈,然后通过本地接口(JNI)( Java Native Interface ),调用本地方法库。
-
JNI作用:开拓Java的使用,融合不同的编程语言为Java所用,Java诞生的时候C、C++横行,想要立足,必须要有调用C、C++的程序。
-
它在内存区域中专门开辟了一块标记区域: Native Method Stack,登记native方法
-
在最终执行的时候,通过本地接口 (JNI),加载本地方法库中的方法
-
如private native void start0();
7.2、 Method Stack & JNI#
本地方法栈(Native Method Stack)
- 它的具体做法是 Native Method Stack 中登记 native方法,
- 在执行引擎执行的时候通过本地接口 (JNI),加载本地方法库(Native Libraies)。
本地接口(Native Interface)JNI
- 本地接口的作用是融合不同的编程语言为Java所用,它的初衷是融合C/C++程序,Java在诞生的时候是C/C++横行的时候,想要立足,必须有调用C、C++的程序,于是就在内存中专门开辟了一块区域处理标记为native的代码,它的具体做法是 在 Native Method Stack 中登记native方法,在 ( ExecutionEngine ) 执行引擎执行的时候加载Native Libraies。
- 目前该方法使用的越来越少了,除非是与硬件有关的应用,比如通过Java程序驱动打印机或者Java系统管理生产设备,在企业级应用中已经比较少见。因为现在的异构领域间通信很发达,比如可以使用Socket通信,也可以使用Web Service等等,不多做介绍!
8、PC寄存器(程序计数器)、方法区、栈、三种JVM、堆#
8.1 PC寄存器#
程序计数器:Program Counter Register
- 每个线程都有一个程序计数器,是线程私有的,就是一个指针,指向方法区中的方法字节码(用来存储指向像一条指令的地址,也即将要执行的指令代码),在执行引擎读取下一条指令,是一个非常小的内存空间,几乎可以忽略不计。
8.2、方法区#
-
方法区存放被所有线程共享的所有字段和方法字节码,以及一些特殊的方法,如构造函数、接口代码也在此定义。简单说,所有定义的方法的信息都保存在此区域,此区域属于共享区间。
-
重点:静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中,但是实例变量和数组的内容存在堆中内存中,和方法区无关。
-
方法区就存:static final Class信息 运行时常量池
-
方法区存放的实例图
常量池
方法区分类:方法区里存储着class文件的信息和动态常量池,class文件的信息包括类信息和静态常量池。
常量池分类:常量池分为静态常量池(class文件常量池)和动态常量池(运行时常量池)。
静态常量池和动态常量池的关系以及区别
- 静态常量池存储的是当class文件被java虚拟机加载进来后存放在方法区的一些字面量和符号引用,字面量包括字符串和基本类型的常量,符号引用其实引用的就是常量池里面的字符串,但字符引用不是直接存储字符串,而是存储字符串在常量池里的索引。
- 动态常量池是当class文件被加载完成后,java虚拟机会将静态常量池的内容转移到动态常量池里,在静态常量池的符号引用一部分是会被转变为直接引用的,比如类的静态方法或私有方法、实例构造方法、父类方法,这是因为这些方法不能被重写其他版本,所以能在加载的时候就可以将符号引用转变为直接引用,而其他的一些方法是在这个方法被第一次调用的时候才会将符号引用转变为直接引用的。
- 动态常量池里的内容除了是静态常量池里的内容外,还将静态常量池里的符号引用转变为直接引用,而且动态常量池里的内容是能动态添加的。例如调用String的intern方法就能将string的值添加到String常量池中,这里String常量池是包含在动态常量池里的,但在jdk1.8后,将String常量池放到了堆中。
使用常量池的好处
常量池是为了避免频繁的创建和销毁对象而影响系统性能,其实现了对象的共享。
例如字符串常量池,在编译阶段就把所有的字符串文字放到一个常量池中。
(1)节省内存空间:常量池中所有相同的字符串常量被合并,只占用一个空间。
(2)节省运行时间:比较字符串时,比equals()快。对于两个引用变量,只用判断引用是否相等,也就可以判断实际值是否相等。
String的intern方法
这个方法首先在常量池中查找是否存在一份equals相等的字符串,如果有的话就返回该字符串的引用,没有的话就将它加入到字符串常量池中,所以存在于class中的常量池并非固定不变的,可以用intern方法加入新的。
搬一下大神博客中的例子
字符串常量池
最最最流行的、最典型的就是字符串了
典型范例:
String a = "abc";
String b = new String("abc");
System.out.println(a == b);
----*----
结果:false
这个是第一个需要理解的地方,a指向哪片内存,b又指向哪片内存呢?对象储存在堆中,这个是不用质疑的,而a作为字面量一开始储存在了class文件中,之后运行期,转存至方法区中。它们两个就不是同一个地方存储的。知道了它之后我们就可以通过实例直接进一步了解了。
实例
String s1 = "Hello";
String s2 = "Hello";
String s3 = "Hel" + "lo";
String s4 = "Hel" + new String("lo");
String s5 = new String("Hello");
String s6 = s5.intern();
String s7 = "H";
String s8 = "ello";
String s9 = s7 + s8;
System.out.println(s1 == s2); // true
System.out.println(s1 == s3); // true
System.out.println(s1 == s4); // false
System.out.println(s1 == s9); // false
System.out.println(s4 == s5); // false
System.out.println(s1 == s6); // true
分析:
1、s1 = = s2 很容易可以判断出来。s1 和 s2 都指向了方法区常量池中的Hello。
2、s1 = = s3 这里要注意一下,因为做+号的时候,会进行优化,自动生成Hello赋值给s3,所以也是true
3、s1 = = s4 s4是分别用了常量池中的字符串和存放对象的堆中的字符串,做+的时候会进行动态调用,最后生成的仍然是一个String对象存放在堆中。
4、s1 = = s9 在JAVA9中,因为用的是动态调用,所以返回的是一个新的String对象。所以s9和s4,s5这三者都不是指向同一块内存
5、s1 = = s6 为啥s1 和 s6地址相等呢? 归功于intern方法,这个方法首先在常量池中查找是否存在一份equal相等的字符串如果有的话就返回该字符串的引用,没有的话就将它加入到字符串常量池中,所以存在于class中的常量池并非固定不变的,可以用intern方法加入新的。
结论:
(1)只有使用引号包含文本的方式创建的String对象之间使用“+”连接产生的新对象才会被加入字符串池中。
(2)对于所有包含new方式新建对象(包括null)的“+”连接表达式,它所产生的新对象都不会被加入字符串池中。
需要注意的特例
1、常量拼接
public static final String a = "123";
public static final String b = "456";
public static void main(String[] args)
{
String c = "123456";
String d = a + b;
System.out.println(c == d);
}
------反编译结果-------
0: ldc #2 // String 123456
2: astore_1
3: ldc #2 // String 123456
5: astore_2
6: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
我们可以发现,对于final类型的常量它们已经在编译中被确定下来,自动执行了+号,把它们拼接了起来,所以就相当于直接”123” + “456”;
A和B都是常量,值是固定的,因此s的值也是固定的,它在类被编译时就已经确定了。也就是说:String d = a + b;等同于:String d=”123”+”456”;
2、static 静态代码块
public static final String a;
public static final String b;
static {
a = "123";
b = "456";
}
public static void main(String[] args)
{
String c = "123456";
String d = a + b;
System.out.println(c == d);
}
------反编译结果-------
3: getstatic #3 // Field a:Ljava/lang/String;
6: getstatic #4 // Field b:Ljava/lang/String;
9: invokedynamic #5, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
上个例子是在编译期间,就已经确定了a和b,但是在这段代码中,编译期static不执行的,a和b的值是未知的,static代码块,在初始化的时候被执行,初始化属于类加载的一部分,属于运行期。看看反编译的结果,很明显使用的是indy指令,动态调用返回String类型对象。一个在堆中一个在方法区常量池中,自然是不一样的。
包装类的常量池技术(缓存)
简单介绍
相信学过java的同学都知道自动装箱和自动拆箱,自动装箱常见的就是valueOf这个方法,自动拆箱就是intValue方法。在它们的源码中有一段神秘的代码值得我们好好看看。除了两个包装类Float和Double 没有实现这个缓存技术,其它的包装类均实现了它。
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer cache[];
static {
// high value may be configured by property
int h = 127;
String integerCacheHighPropValue =
VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
if (integerCacheHighPropValue != null) {
try {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
} catch( NumberFormatException nfe) {
// If the property cannot be parsed into an int, ignore it.
}
}
high = h;
cache = new Integer[(high - low) + 1];
int j = low;
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
// range [-128, 127] must be interned (JLS7 5.1.7)
assert IntegerCache.high >= 127;
}
private IntegerCache() {}
}
分析:我们可以看到从-128~127的数全部被自动加入到了常量池里面,意味着这个段的数使用的常量值的地址都是一样的。一个简单的实例
Integer i1 = 40;
Integer i2 = 40;
Double i3 = 40.0;
Double i4 = 40.0;
System.out.println("i1=i2 " + (i1 == i2));
System.out.println("i3=i4 " + (i3 == i4));
-----结果----
true
false
原理如下:
1、== 这个运算在不出现算数运算符的情况下 不会自动拆箱,所以i1 和 i 2它们不是数值进行的比较,仍然是比较地址是否指向同一块内存
2、它们都在常量池中存储着,类似于这样
3、编译阶段已经将代码转变成了调用valueOf方法,使用的是常量池,如果超过了范围则创建新的对象
Integer i1=40;
Java在编译的时候会直接将代码封装成Integer i1=Integer.valueOf(40);
,从而使用常量池中的对象。
复杂实例[-128~127]
Integer i1 = 40;
Integer i2 = 40;
Integer i3 = 0;
Integer i4 = new Integer(40);
Integer i5 = new Integer(40);
Integer i6 = new Integer(0);
System.out.println("i1=i2 " + (i1 == i2));
System.out.println("i1=i2+i3 " + (i1 == i2 + i3));
System.out.println("i1=i4 " + (i1 == i4));
System.out.println("i4=i5 " + (i4 == i5));
System.out.println("i4=i5+i6 " + (i4 == i5 + i6));
System.out.println("40=i5+i6 " + (40 == i5 + i6));
----结果----
(1)i1=i2 true
(2)i1=i2+i3 true
(3)i1=i4 false
(4)i4=i5 false
(5)i4=i5+i6 true
(6)40=i5+i6 true
它们的内存分布大概如下
注意点:
1、当出现运算符的时候,Integer不可能直接用来运算,所以会进行一次拆箱成为基本数字进行比较
2、==这个符号,既可以比较普通基本类型,也可以比较内存地址看比较的是什么了
分析:
(1)号成立不用多说
(2)号成立是因为运算符自动拆箱
(3)(4)号是因为内存地址不同
(5)(6)号都是自动拆箱的结果
PS:equals方法比较的时候不会处理数据之间的转型,比如Double类型和Integer类型。
解释:语句i4 == i5 + i6,因为+这个操作符不适用于Integer对象,首先i5和i6进行自动拆箱操作,进行数值相加,即i4 == 40。然后Integer对象无法与数值进行直接比较,所以i4自动拆箱转为int值40,最终这条语句转为40 == 40进行数值比较。
超过范围
假设一下,如果超出了这个范围之后呢?正如前文所言,所有的都将成为新的对象
Integer i1 = 400;
Integer i2 = 400;
Integer i3 = 0;
Integer i4 = new Integer(400);
Integer i5 = new Integer(400);
Integer i6 = new Integer(0);
Integer i7 = 1;
Integer i8 = 2;
Integer i9 = 3;
System.out.println("i1=i2 " + (i1 == i2));
System.out.println("i1=i2+i3 " + (i1 == i2 + i3));
System.out.println("i1=i4 " + (i1 == i4));
System.out.println("i4=i5 " + (i4 == i5));
System.out.println("i4=i5+i6 " + (i4 == i5 + i6));
System.out.println("400=i5+i6 " + (400 == i5 + i6));
----结果----
i1=i2 false
i1=i2+i3 true
i1=i4 false
i4=i5 false
i4=i5+i6 true
400=i5+i6 true
8.3、栈 Stack#
- 在计算机流传有一句废话: 程序 = 算法 + 数据结构
- 但是对于大部分同学都是: 程序 = 框架 + 业务逻辑
- 栈:后进先出 / 先进后出
- 队列:先进先出(FIFO : First Input First Output)
栈管理程序运行
- 存储一些基本类型的值、对象的引用、方法等
- 栈的优势是,存取速度比堆要快,仅次于寄存器,栈数据可以共享。
为什么 main 方法最先执行,但最后结束?——栈
说明:
- 栈也叫栈内存,主管Java程序的运行,是在线程创建的时创建,它的生命周期是跟随线程的生命周期,线程结束栈内存也就释放了。
- 对于栈来说不存在垃圾回收问题,只要线程一旦结束,该栈就Over,生命周期和线程一致,是线程私有的。
- 方法自己调用自己就会导致栈溢出(递归死循环测试)。
栈里面会放什么?
- 8大基本类型 + 对象的引用 + 实例的方法
栈的运行原理
- Java栈的组成元素------栈帧。
- 栈帧:是一种用于帮助虚拟机执行方法调用于方法执行的数据结构。他是独立于线程的,一个线程有自己的一个栈帧。封装了方法的局部变量表,动态链接信息、方法的返回地址以及操作数栈等信息。
- 第一个方法从调用开始到执行完成,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
当一个方法A被调用时就产生了一个栈帧F1,并被压入到栈中,A方法又调用了B方法,于是产生了栈帧F2也被压入栈中,B方法又调用了C方法,于是产生栈帧F3也被压入栈中 执行完毕后,先弹出F3, 然后弹出F2,在弹出F1........
遵循“先进后出” / “后进先出” 的原则。
栈满了,抛出异常:stackOverflowError
8.4、三种JVM#
- Sun公司的Hotspot™64-Bit server vw (build 25.181-b13,mixed mode)
- BEA JRockit
- IBM 39 VM
我们都是学的Hotspot
8.5、堆#
一个JVM仅有一个堆内存,堆内存大小可以调节
1、JVM内存划分为堆内存和非堆内存
- 堆内存分为年轻代(Young Generation)、老年代(Old Generation),
- 非堆内存就一个永久代(Permanent Generation)。(这个非堆,严格意义上来说也是堆,但逻辑操作上又不是堆…)
2、年轻代分为Eden和Survivor区
- Survivor区由FromSpace和ToSpace组成。(谁空谁是to)
- Eden区占大容量,Survivor两个区占小容量,默认比例是8:1:1
3、堆内存用途:
- 存放的是对象,垃圾收集器就是收集这些对象,然后根据GC算法回收
4、老年代:
- 在新生代中经历了多次(默认是15次,具体看虚拟机配置的阀值)GC后仍然存活下来的对象会进入老年代中
- 老年代中的对象生命周期较长,存活率比较高
- 在老年代中进行GC的频率相对而言较低,而且回收的速度也比较慢
5、非堆内存用途:
- 永久代,也叫方法区存储类信息、常量、静态变量、即时编译器编译后的代码等数据,对这一区域而言,Java虚拟机规范指出可以不进行垃圾收集,一般而言不会进行垃圾回收。
分代概念
1、新生成的对象首先放到年轻代Eden区,当Eden空间满了,出发Minor GC,存活下来的对象移动到Survivor0区,Survivor0区满后触发执行Minor GC,Survivor0区存活对象移动到Suvivor1区,这样保证了一段时间内总有一个survivor区为空。经过多次Minor GC仍然存活的对象移动到老年代。
2、老年代存储长期存活的对象,占满时会触发Major GC=Full GC,GC期间会停止所有线程等待GC完成,所以对响应要求高的应用尽量减少发生Major GC,避免响应超时。
- Minor GC : 清理年轻代
- Major GC(Full GC) : 清理老年代,清理整个堆空间,包括年轻代和永久代
- 所有GC都会停止应用所有线程。
元空间
在JDK1.8版本废弃了永久代,替代的是元空间(MetaSpace),元空间于永久代上类似,都是方法区的实现,他们最大区别就是:元空间并不在JVM中,而是使用本地内存。
元空间有注意有两个参数:
- MetaspaceSize :初始化元空间大小,控制发生GC阈值
- MaxMetaspaceSize : 限制元空间大小上限,防止异常占用过多物理内存
移除永久代原因
为融合HotSpot JVM于JRockit VM(新JVM技术)而做出的改变,因为JRockit没有永久代。有了元空间就不再会出现永久代OOM问题了!
新生区、老年区
- 新生区是类诞生、成长、消亡的区域,一个类在这里产生,应用,最后被垃圾回收器收集,结束生命。
- 新生区又分为两部分:伊甸区(Eden Space)和幸存者区(Survivor Space),所有的类都是在伊甸区被new出来的,幸存区有两个:0区和1区,当伊甸区的空间用完时,程序又需要创建对象,JVM的垃圾回收器将对伊甸区进行垃圾回收(Minor GC)。将伊甸区中的剩余对象移动到幸存0区,若幸存0区也满了,再对该区进行垃圾回收,然后移动到1区,若养老区也满了,那么这个时候将产生Major GC(Full GC),进行养老区的内存清理,若养老区执行了Full GC后依然无法进行对象的保存,就会产生OOM异常 “OutOfMemoryError ”。若出现java.lang.OutOfMemoryError:java heap space异常,说明Java虚拟机的堆内存不够,原因如下:
- 1、Java虚拟机的堆内存设置不够,可以通过参数 -Xms(初始值大小),-Xmx(最大大小)来调整。
- 2、代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)或者死循环。
- 真理:经过研究,99%的对象都是临时对象
何时触发Minor GC 或FullGC?
Minor GC的触发时常在发生,当新生代的Dden区满了之后就会触发Minor GC。
Full GC:
- 发生Minor GC之前先进行检查,如果“老年代可用的连续内存空间” < “新生代历次Minor GC后升入老年代的对象总和的平均大小”,说明本次Minor GC后可能升入老年代的对象大小,可能超过了老年代当前可用的内存空间,此时会触发FullGC
- 当老年代没有足够空间存放对象时,会触发一次FullGC
- 如果元空间区域的内存达到了所设定的阈值-XX:MetaspaceSize=,也会触发FullGC
堆内存溢出
永久区(Perm)
- 永久存储区是一个常驻内存区域,用于存放JDK自身所携带的Class,Interface的元数据,也就是说它存储的是运行环境必须的类信息,被装载进此区域的数据是不会被垃圾回收器回收掉的,关闭JVM才会释放此区域所占用的内存。
- 如果出现 java.lang.OutOfMemoryError:PermGen space,说明是Java虚拟机对永久代Perm内存设置不够。一般出现这种情况,都是程序启动需要加载大量的第三方Jar包。
- 例如:在一个Tomcat下部署了太多的应用。或者大量动态反射生成的类不断被加载,最终导致Perm区被占满。
注意:
- JDK1.6之前:有永久代,常量池1.6在方法区;
- JDK1.7:有永久代,但是已经逐步 “去永久代”,常量池在堆;
- JDK1.8及之后:无永久代,常量池1.8在元空间。
熟悉三区结构后方可学习JVM垃圾回收机制:
- 实际而言,方法区(Method Area)和堆一样,是各个线程共享的内存区域,它用于存储虚拟机加载的:类信息+普通常量+静态常量+编译器编译后的代码。虽然JVM规范将方法区描述为 堆的一个逻辑部分,但它却还有一个别名,叫做Non-Heap(非堆),目的就是要和堆分开。
- 对于HotSpot虚拟机,很多开发者习惯将方法区称之为 “永久代(Parmanent Gen)”,但严格本质上说两者不同,或者说使用永久代实现方法区而已,永久代是方法区(相当于是一个接口interface)的一个实现,Jdk1.7的版本中,已经将原本放在永久代的字符串常量池移走。
- 常量池(Constant Pool)是方法区的一部分,Class文件除了有类的版本,字段,方法,接口描述信息外,还有一项信息就是常量池,这部分内容将在类加载后进入方法区的运行时常量池中存放!
探究:
1.什么时候在永久区就崩了呢?
一个启动类,加载了大量的第三方jar包。
Tomcat 部署了太多的应用
大量动态生成反射类,不断地被加载
直到内存满,就会出现 OOM
2.元空间
逻辑上存在,物理上不存在 (因为存储在本地磁盘内) 所以最后并不算在JVM虚拟机内存中
9、堆内存调优#
9.1 概述#
System.out.println(“最大内存Max_memory=”+Runtime.getRuntime().maxMemory()/(double)1024/1024+”M”);
System.out.println(“初始化内存大小Total_memory=”+Runtime.getRuntime().totalMemory()/(double)1024/1024+”M”);
JVM内存分析
IDEA中进行VM调优参数设置,然后启动
- 发现默认的情况下,分配的内存时总内存的1/4,而初始化的内存为 1/64 !
- VM参数调优:把初始内存,和总内存都调为 1024M,运行,查看结果!
-Xms1024m -Xmx1024m -XX:+PrintGCDetails
我们来分析一下:
(305664 + 699392)/ 1024 = 981.5
再次证明,元空间并不在虚拟机中,而是使用本地内存。
测试2
package github.JVM.Demo02;
import java.util.Random;
/**
* @author subeiLY
* @create 2021-06-08 10:22
*/
public class Demo02 {
public static void main(String[] args) {
String str = "suneiLY";
while (true) {
str += str + new Random().nextInt(88888888)
+ new Random().nextInt(999999999);
}
}
}
- vm参数:
-Xms8m -Xmx8m -XX:+PrintGCDetails
-
测试,查看结果!
-
这是一个young 区域撑爆的JAVA 内存日志,其中 PSYoungGen 表示 youngGen分区的变化1536k 表示 GC 之前的大小。
488k 表示GC 之后的大小。 -
整个Young区域的大小从 1536K 到 672K , young代的总大小为 7680K。
-
user – 总计本次 GC 总线程所占用的总 CPU 时间。
-
sys – OS 调用 or 等待系统时间。
-
real – 应用暂停时间。
-
如果GC 线程是 Serial Garbage Collector 串行搜集器的方式的话(只有一条GC线程,), real time 等于user 和 system 时间之和。
-
通过日志发现Young的区域到最后 GC 之前后都是0,old 区域 无法释放,最后报堆溢出错误。
JVM内存分析
JVM内存排错
遇到 OOM:堆空间错误
- 尝试扩大堆内存(设置 VM Options),查看结果-Xms1024m -Xmx1024m -XX:+PrintGCDetails
- 如果解决,说明是默认分配的内存不够
- 分析内存,看一下哪里出现了问题(专业工具)
//改成小内存执行Jvm
// -Xms8m -Xmx8m -XX:+PrintGCDetails
// -Xms 设置初始化内存分配大小 1/64
// -Xmx 设置最大分配内存,默认 1/4
// -XX:+PrintGCDetails :控制台打印 GC 的回收信息
// -XX:+HeapDumpOnOutOfMemoryError :输出 OOM dump 信息
public static void main(String[] args){
// String 这种类型,是在堆空间中的
String str = "adsadasdasdsa";
while(true){
str += str + new Random().nextInt(888888888)+new Random().nextInt(99999999);
}
}
JProfile
1、Dump内存快照
在运行java程序的时候,有时候想测试运行时占用内存情况,这时候就需要使用测试工具查看了。在eclipse里面有 Eclipse Memory Analyzer tool(MAT)**插件可以测试,而在idea中也有这么一个插件,就是JProfiler,一款性能瓶颈分析工具!
- 作用:
- 分析Dump文件,快速定位内存泄露;
- 获得堆中对象的统计数据;
- 获得对象相互引用的关系;
- 采用树形展现对象的相互吸引的情况;
- Jprofile在IDEA中安装
- Jprofile在电脑中安装
安装参考博客:https://blog.csdn.net/llx522/article/details/124881260
下载地址:https://www.ej-technologies.com/download/jprofiler/files
客户端和服务器安装的版本需要统一,安装包都是一样的,推荐 11.1 版本。
客户端的机器也需要安装 JDK,我安的是 JDK8。
安装时需要本地有网络,如果没有网络,他会提示输入一个 license,可以找个有网的环境输入邮箱申请试用 license。
下载完双击运行,选择自定义目录安装,点击Next。
注册
// 注册码仅供大家参考
L-Larry_Lau@163.com#23874-hrwpdp1sh1wrn#0620
L-Larry_Lau@163.com#36573-fdkscp15axjj6#25257
L-Larry_Lau@163.com#5481-ucjn4a16rvd98#6038
L-Larry_Lau@163.com#99016-hli5ay1ylizjj#27215
L-Larry_Lau@163.com#40775-3wle0g1uin5c1#0674
- Settings–Tools–JProflier–JProflier executable选择JProfile安装可执行文件。(如果系统只装了一个版本, 启动IDEA时会默认选择)保存。
如果刚刚下载完或者下载重启完的IDEA中没有JproFile,需要清理一下IDEA的内存再重启
- 代码测试
package github.JVM.Demo02;
import java.util.ArrayList;
/**
* @author subeiLY
* @create 2021-06-08 11:13
*/
public class Demo03 {
byte[] byteArray = new byte[1*1024*1024]; // 1M = 1024K
public static void main(String[] args) {
ArrayList<Demo03> list = new ArrayList<>();
int count = 0;
try {
while (true) {
list.add(new Demo03()); // 问题所在
count = count + 1;
}
} catch (Error e) {
System.out.println("count:" + count);
e.printStackTrace();
}
}
}
- 参数设置
-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
- 得到错误信息文件(Dump文件)
- 用 JProfile打开
- 分析
- 从软件开发的角度上,dump文件就是当程序产生异常时,用来记录当时的程序状态信息(例如堆栈的状态),用于程序开发定位问题。
10、GC四大算法#
10.1、引用计数法#
- 每个对象有一个引用计数器,当对象被引用一次则计数器加1,当对象引用失效一次,则计数器减1,对于计数器为0的对象意味着是垃圾对象,可以被GC回收。
- 目前虚拟机基本都是采用可达性算法,从GC Roots 作为起点开始搜索,那么整个连通图中的对象边都是活对象,对于GC Roots 无法到达的对象变成了垃圾回收对象,随时可被GC回收。
10.2、复制算法#
- 年轻代中使用的是Minor GC,采用的就是复制算法(Copying)。
什么是复制算法
- Minor GC 会把Eden中的所有活的对象都移到Survivor区域中,如果Survivor区中放不下,那么剩下的活的对象就被移动到Old generation中,也就是说,一旦收集后,Eden就是变成空的了
- 当对象在Eden(包括一个Survivor区域,这里假设是From区域)出生后,在经过一次Minor GC后,如果对象还存活,并且能够被另外一块Survivor区域所容纳 (上面已经假设为from区域,这里应为to区域,即to区域有足够的内存空间来存储Eden 和 From 区域中存活的对象),则使用复制算法将这些仍然还活着的对象复制到另外一块Survivor区域(即 to 区域)中,然后清理所使用过的Eden 以及Survivor 区域(即form区域),并且将这些对象的年龄设置为1,以后对象在Survivor区,每熬过一次MinorGC,就将这个对象的年龄 + 1,当这个对象的年龄达到某一个值的时候(默认是15岁,通过- XX:MaxTenuringThreshold 设定参数)这些对象就会成为老年代。
- -XX:MaxTenuringThreshold 任期门槛=>设置对象在新生代中存活的次数
面试题:如何判断哪个是to区呢?一句话:谁空谁是to
原因解释:
- 年轻代中的GC,主要是复制算法(Copying)
- HotSpot JVM 把年轻代分为了三部分:一个Eden区和2个Survivor区(from区和to区)。默认比例8:1:1,一般情况下,新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后,如果仍然存活,将会被移到Survivor区,对象在Survivor中每熬过一次Minor GC , 年龄就会增加1岁,当它的年龄增加到一定程度时,就会被移动到年老代中,因为年轻代中的对象基本上 都是朝生夕死,所以在年轻代的垃圾回收算法使用的是复制算法!复制算法的思想就是将内存分为两块,每次只用其中一块,当这一块内存用完,就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片!
- 在GC开始的时候,对象只会在Eden区和名为“from“的Survivor区,Survivor区”TO“是空的,紧接着进行GC ,Eden区中所有存活的对象都会被复制到”TO“,而在”From“区中,仍存活的对象会更具他们的年龄值来决定去向。
- 年龄达到一定值的对象会被移动到老年代,没有达到阈值的对象会被复制到“TO”区域,经过这次GC后,Eden区和From区已经被清空,这个时候,“From”和”TO“会交换他们的角色,也就是新的”TO“就是GC前的”From“,新的”From“就是上次GC前的”TO“。
- 不管怎样,都会保证名为“TO”的Survivor区域是空的。Minor GC会一直重复这样的过程。直到TO区被填满,“TO”区被填满之后,会将所有的对象移动到老年代中。
- 因为Eden区对象一般存活率比较低,一般的,使用两块10%的内存作为空闲和活动区域,而另外80%的内存,则是用来给新建对象分配内存的一旦发生GC,将10%的from活动区间与另外80%中存活的Eden对象转移到10%的to空闲区间,接下来,将之前的90%的内存,全部释放,以此类推;
- 好处:没有内存碎片;坏处:浪费内存空间。
劣势:
- 复制算法它的缺点也是相当明显的。
- 他浪费了一半的内存,这太要命了。
- 如果对象的存活率很高,我们可以极端一点,假设是100%存活,那么我们需要将所有对象都复制一遍,并将所有引用地址重置一遍。复制这一工作所花费的时间,在对象存活率达到一定程度时,将会变的不可忽视,所以从以上描述不难看出。复制算法想要使用,最起码对象的存活率要非常低才行,而且最重要的是,我们必须要客户50%的内存浪费。
10.3、标记清除(Mark-Sweep)#
- 回收时,对需要存活的对象进行标记;
- 回收不是绿色的对象。
- 当堆中的有效内存空间被耗尽的时候,就会停止整个程序(也被称为stop the world),然后进行两项工作,第一项则是标记,第二项则是清除。
- 标记:从引用根节点开始标记所有被引用的对象,标记的过程其实就是遍历所有的GC Roots ,然后将所有GC Roots可达的对象,标记为存活的对象。
- 清除:遍历整个堆,把未标记的对象清除。
- 缺点:这个算法需要暂停整个应用,会产生内存碎片。两次扫描,严重浪费时间。
用通俗的话解释一下 标记/清除算法,就是当程序运行期间,若可以使用的内存被耗尽的时候,GC线程就会被触发并将程序暂停,随后将依旧存活的对象标记一遍,最终再将堆中所有没被标记的对象全部清 除掉,接下来便让程序恢复运行。
劣势:
- 首先,它的缺点就是效率比较低(递归与全堆对象遍历),而且在进行GC的时候,需要停止应用程序,这会导致用户体验非常差劲。
- 其次,主要的缺点则是这种方式清理出来的空闲内存是不连续的,这点不难理解,我们的死亡对象都是随机的出现在内存的各个角落,现在把他们清除之后,内存的布局自然乱七八糟,而为了应付这一点,JVM就不得不维持一个内存空间的空闲列表,这又是一种开销。而且在分配数组对象的时候,寻找连续的内存空间会不太好找。
10.4、标记压缩#
- 标记整理说明:老年代一般是由标记清除或者是标记清除与标记整理的混合实现。
什么是标记压缩?
原理:
- 在整理压缩阶段,不再对标记的对象作回收,而是通过所有存活对象都向一端移动,然后直接清除边界以外的内存。可以看到,标记的存活对象将会被整理,按照内存地址依次排列,而未被标记的内存会被清理掉,如此一来,当我们需要给新对象分配内存时,JVM只需要持有一个内存的起始地址即可,这比维护一个空闲列表显然少了许多开销。
- 标记、整理算法不仅可以弥补标记、清除算法当中,内存区域分散的缺点,也消除了复制算法当中,内存减半的高额代价。
10.5、标记清除压缩#
- 标记清除几次,再压缩
10.6、总结#
- 内存效率(时间复杂度):复制算法 > 标记清除算法 > 标记清除压缩算法
- 内存整齐度:复制算法 = 标记压缩算法 > 标记清除算法
- 内存利用率:标记压缩算法 = 标记清除算法 > 复制算法
可以看出,效率上来说,复制算法是当之无愧的老大,但是却浪费了太多内存,而为了尽量兼顾上面所提到的三个指标,标记压缩算法相对来说更平滑一些,但是效率上依然不尽人意,它比复制算法多了一个标记的阶段,又比标记清除多了一个整理内存的过程。
难道就没有一种最优算法吗?
答案: 无,没有最好的算法,只有最合适的算法 。 -----------> 分代收集算法
年轻代 :(Young Gen)
- 年轻代特点是区域相对老年代较小,对象存活低。
- 这种情况复制算法的回收整理,速度是最快的。复制算法的效率只和当前存活对象大小有关,因而很适用于年轻代的回收。而复制算法内存利用率不高的问题,通过hotspot中的两个survivor的设计得到缓解。
老年代:(Tenure Gen)
- 老年代的特点是区域较大,对象存活率高!
- 这种情况,存在大量存活率高的对象,复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。Mark阶段的开销与存活对象的数量成正比,这点来说,对于老年代,标记清除或 者标记整理有一些不符,但可以通过多核多线程利用,对并发,并行的形式提高标记效率。Sweep阶段的 开销与所管理里区域的大小相关,但Sweep “就地处决” 的 特点,回收的过程没有对象的移动。使其相对其他有对象移动步骤的回收算法,仍然是是效率最好的,但是需要解决内存碎片的问题。
11、JMM#
- 什么是JMM?
- JMM:(java Memory Model的缩写)
- 他干嘛的?官方,其他人的博客,对应的视频!
- 作用:缓存一致性协议,用于定义数据读写的规则(遵守,找到这个规则)。
- JMM定义了线程工作内存和主内存之间的抽象关系:线程之间的共享变量存储在主内存(Main Memory)中,每个线程都有一个私有的本地内存(Local Memory)。
- 解决共享对象可见性这个问题:volilate
它该如何学习?
- 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规则来进行分析。
作者:mountainstudy
出处:https://www.cnblogs.com/mountainstudy/p/16977328.html
版权:本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」许可协议进行许可。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义