线程私有
可以看做是当前线程执行字节码的行号指示器。
是Java虚拟机规定的唯一不会发生内存溢出的区域。
线程私有
每个Java方法执行时都会创建一个栈帧用于存储局部变量表、 操作数栈、动态链接、方法出口等信息。
每一个Java方法从调用到执行完成的过程就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
也叫native栈,线程私有
虚拟机栈为虚拟机执行Java方法服务;
本地方法栈则为虚拟机用到的Native方法服务。
线程共享区域-虚拟机启动时创建
堆内存主要用于存放对象和数组
是JVM管理的内存中最大的一块区域
线程共享区-虚拟机启动时创建
存储以被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
jdk1.8去除永久代,将方法区称为元空间,去除原因如下:
①字符串存在永久代中,容易出现性能问题和内存溢出。
②类及方法的信息等比较难确定其大小,因此对于永久代的大小指定比较困难,太小容易出现永久代溢出,太大则容易导致老年代溢出。
③永久代增加了 GC 的复杂度,回收效率不高。
元空间并不在虚拟机中,而是使用本地内存
元空间的大小仅受本地内存限制,但可以通过-XX:MetaspaceSize和
-XX:MaxMetaspaceSize来指定元空间的大小。
①.普通对象的创建过程
虚拟机遇到一条new指令时,首先检查这个指令的参数(类的类型)是否能在常量池中定位到一个类的符号引用
并且检查这个符号引用代表的类时候已经被加载、解析、初始化过,如果没有要执行类加载过程。
②.数组对象的创建
虚拟机遇到一条newarray字节码指令会在内存中直接分配一块区域。
③.Class对象的创建
在虚拟机加载类的时候,通过类的全限定名获取此类的二进制字节流,再通过文件验证后把字节流代表的静态结构转化为方法区的运行时数据结构。
并且在内存中生成一个代表这个类的Class对象,存在方法区中,作为这个类的各种数据的访问入口。
对象在内存中的布局分为三块区域:对象头、实例数据、对齐填充
对象头:存储对象自身的运行时数据,包括哈希吗,GC分代年龄,锁状态标识,线程持有的锁,偏向线程ID,偏向时间戳等;
对象头的另外一部分是类型指针,即对象指向它在方法区中的类元数据的指针,虚拟机通过这个指针来确定该对象是哪个类的实例。
如果对象是一个数组,对象头还有一块用语记录数组长度的数据。
实例数据:对象真正存储的有效信息,是在类中定义的各种类型的字段内容。
对齐填充:虚拟机要求对象的大小必须是8字节的整数倍,对齐填充起占位符的作用,保证对象大小为8字节的整数倍。
Java程序通过栈上的引用数据操作堆中的具体对象,对象访问方式有两种:句柄访问,直接指针访问。
句柄访问:Java堆划分出一块区域用作句柄池,引用中存储对象的句柄地址,句柄中才实际包含着对象实例数据和对象类型数据各自的具体地址信息。
直接指针访问:栈中的引用直接指向对象在堆中的地址,对象在头数据中指向方法区中其类元数据的地址。
使用句柄的好处是引用中存储的是稳定的句柄地址,在对象被移动(垃圾回收导致对象的移动)时只会改变局并重的实例数据指针。使用直接指针访问的好处是速度更快。
-Xmx:最大堆大小
-Xms:初始堆大小
-Xmn:年轻代大小
-XXSurvivorRatio:年轻代中Eden区与Survivor区的大小比值
例如:-Xmx10240m -Xms10240m -Xmn5120m -XXSurvivorRatio=3
年轻代5120m, Eden:Survivor=3,Survivor区大小=1024m(Survivor区有两个,即将年轻代分为5份,每个Survivor区占一份),总大小为2048m。
-Xms初始堆大小即最小内存值为10240m
Java内存模型定义了一种多线程访问Java内存的规范:
(1)Java内存模型将内存分为了主内存和工作内存。类的状态是存储在主内存中的,每次Java线程用到这些主内存中的变量的时候,都会读一次主内存中的变量,并将这些变量在自己的线程的工作内存中保存一份拷贝,当运行自己线程的代码时候,操作的都是自己工作内存中的变量副本。在线程代码执行完毕之后,会将最新的值更新到主内存中去。
(2)定义了8个原子操作,用于操作主内存和工作内存中的变量的交互。
(3)定义了volatile变量,保证了变量的可视性。
(4)原子性、可见性、有序性。
(5)happens-before:针对变量的可见性制定的一些通用规则,比如定义了操作A必然先行发生于操作B的一些规则,比如在同一个线程内控制流前面的代码一定先行发生于控制流后面的代码、一个释放锁unlock的动作一定先行发生于后面对于同一个锁进行锁定lock的动作等等,只要符合这些规则,则不需要额外做同步措施,如果某段代码不符合所有的happens-before规则,则这段代码一定是线程非安全的。
主要通过new关键字来实现:
首先判断有没有类加载,没有加载过就先加载类----》
为新生对象分配内存–》
内存初始化–》
对象的必要设置。
对象内存布局:对象头、实例数据、对齐填充。
访问定位:通过虚拟机栈上的reference 数据来操作堆上面具体对象。
Hotspot使用的是直接指针。reference直接指向Java堆上的对象指针。
理论上说上 32 位的 JVM 堆内存可以到达 2^32,即 4GB,但实际上会比这个小很多。不同操作系统之间不同,如 Windows 系统大约 1.5 GB,Solaris 大约 3GB。
64 位 JVM允许指定最大的堆内存,理论上可以达到 2^64,这是一个非常大的数字,实际上你可以指定堆内存大小到 100GB。甚至有的 JVM,如 Azul,堆内存到 1000G 都是可能的。
(1)指针碰撞:跟踪在Eden上新创建的对象。当有新对象创建,只需要判断新创建对象的大小是否满足剩余的Eden空间。如果新对象满足要求,则其会被分配到Eden空间,同样位于Eden的最上面。所以当有新对象创建时,只需要判断此新对象的大小即可,因此具有更快的内存分配速度
(2)TBAL:在多线程环境下进行内存分配难免要进行加锁,但是我们可以对每个线程分配一个小片空间,这个空间是线程私有的,就可以实现在不加锁情况下的并发分配内存。
类加载器(ClassLoader)
运行时数据区(Runtime Data Area)
执行引擎(Execution Engine)
本地库接口(Native Interface)
组件的作用: 首先通过类加载器(ClassLoader)会把 Java 代码转换成字节码,运行时数据区(Runtime Data Area)再把字节码加载到内存中,而字节码文件只是 JVM 的一套指令集规范,并不能直接交个底层操作系统去执行,因此需要特定的命令解析器执行引擎(Execution Engine),将字节码翻译成底层系统指令,再交由 CPU 去执行,而这个过程中需要调用其他语言的本地库接口(Native Interface)来实现整个程序的功能。
https://www.cnblogs.com/ThinkVenus/p/6805495.html
堆内存的OOM异常
a)如何产生?
堆内存用于存储实例对象,当我们不断创建对象,并且对象都有引用指向(GC Roots到对象之间有可达路径),那么垃圾回收机制就不会清理这些对象,当对象多到挤满堆内存的上限后,就产生OOM异常。
b)模拟堆内存OOM异常
PS:在eclipse的Arguments中可以设置VM arguments,这就是JVM的一些参数。
-Xms:设置堆的最小值
-Xmx:设置堆的最大值
public class A(){
public static void main(String[] args){
while(true){
new Person();
}
}
}//运行结果中出现:java.lang.OutOFMemory:Java heap space//说明是在堆内存中发生了OOM异常。
c)如何解决?
使用内存映像分析工具:Eclipse Memory Analyzer对dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,即要搞明白是内存泄漏还是内存溢出。
PS:内存泄漏导致的OOM:new出来的很多对象已经不需要了,但仍然有引用指向,所以垃圾回收机制无法回收。
PS:内存溢出:new出来的对象都是需要的,但堆内存太小装不下了。
如果是内存泄漏,通过工具查看泄漏对象到GC Roots的引用链。找到泄漏对象是通过怎样的路径与GC Roots发生关联,然后导致垃圾回收机制无法自动回收的。
如果不存在内存泄漏,也就是所有的对象都必须存在,这时候就调大堆内存。
JVM栈和本地方法栈的OOM异常
a)StackOverFlowError
当线程请求的栈深度大于虚拟机所允许的最大栈深度,就会抛出这个异常。
b)OutOfMemeoryError
当虚拟机要扩展栈时无法申请到足够空间的内存,就会抛出这个异常。
PS:这两种异常其实是对同一个问题的两种描述。在单一线程下,不论是栈帧太大还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是StackOverFlowError。通过测试发现,如果给每个线程的JVM栈分配的内存越大,大的栈帧在这个JVM栈中也能装得下,理应StackOverFlowError会减少,但事实却恰恰相反:当每个线程的JVM栈越大,那么所能创建的线程数就越少,稍微建立几个线程可能就会把有限的内存资源耗尽。
运行时常量池的OOM异常
我们通过String类的intern()方法向方法区中的常量池添加内容。
intern方法的作用是:当常量池中已经有这个String类型所对应的字符串的话,就返回这个字符串的引用;如果常量池中没有这个字符串的话就将这个字符串添加到常量池中,再返回这个字符串的引用。
方法区的OOM异常
a)如何产生?
方法区中存放的是Class的相关信息,如:类名、访问修饰符、常量池、字段描述、方法描述等。
如果产生大量的类就有可能将方法区填满,从而产生方法区的OOM异常。
b)注意点
方法区的OOM异常是非常常见的,特别是在一些动态生成大量Class的应用中(JSP),需要特别注意类的回收。
本机直接内存的OOM异常
(1)引用计数算法:引用一次加1,失效就减1. 但是不能解决互相引用的情况。
(2)可达性分析算法:通过一系列称为“GC Roots”的对象作为起始点,从这些节点向下搜索,搜索所走过的路径称为引用链,当一个对象到GC Roots没有任何引用链(即从GC Roots到对象不可达)时,则证明此对象是不可用的。
(1)标记-清除算法:首先标记出所有需要回收的对象,标记完成后统一回收所有被标记的对象。
A)缺点:标记和清除效率不高;会存在大量的不连续内存碎片
(2)复制算法----新生代才采用的算法:将可用内存分为两块,每次只用其中一块,当这一块内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已经使用过的内存空间一次性清理掉。
A)缺点:内存缩小为原来的一半,内存的损失太大。
B)解决方法:将内存分为较大的Eden区域和两个较小的Survivor区域,每次回收将Eden中和Survivor中还存活的对象移动到另一块空的Survivor区域中。
(3)标记整理算法----老年代常采用算法:过程与标记-清除算法一样,不过不是直接对可回收对象进行清理,而是让所有存活对象都向一端移动,然后直接清理掉边界以外的内存。
(4)分代收集算法:在Java中把堆分为新生代和老年代,然后根据各块的特点采用最适当的收集算法,其实也就是上面几种算法的结合使用。
1)可达性分析对执行时间的敏感点的一个体现就是GC停顿上面,可达性分析工作必须在一个能确保一致性的快照中进行–这里的一致性是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上,不可以出现分析过程中对象引用关系还在不断变化的情况,该点不满足就无法得到保证。这一点是导致GC进行时必须停顿所有Java执行线程(sun称为 “Stop the world”)的其中一个重要原因。
2)安全点:在HotSpot虚拟机中,借助于OopMap这种数据结构的协助下,可以快速且准确的完成GCRoots的枚举。但是不可能为每条指令都生成OopMap,这样空间成本就非常高。所以HotSpot中只是在“特定的位置”记录了这些信息,这些位置称为安全点,即程序执行时并非在所有地方都停顿下来开始GC,只有到达安全点时才能暂停。
(1)Serial收集器—新生代
这个收集器是一个采用复制算法的单线程的收集器,单线程一方面意味着它只会使用一个CPU或一条线程去完成垃圾收集工作,另一方面也意味着它进行垃圾收集时必须暂停其他线程的所有工作,直到它收集结束为止。
(2)ParNew收集器—新生代
ParNew收集器其实就是Serial收集器的多线程版本,除了使用多条线程进行垃圾收集之外,其余行为都与Serial收集器完全一样,包括使用的也是复制算法。
(3)Parallel收集器—新生代
Parallel收集器也是一个新生代收集器,也是用复制算法的收集器,也是并行的多线程收集器,但是它的特点是它的关注点和其他收集器不同。介绍这个收集器主要还是介绍吞吐量的概念。CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间,而Parallel收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量的意思就是CPU用于运行用户代码时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总运行100分钟,垃圾收集1分钟,那吞吐量就是99%。另外,Parallel收集器是虚拟机运行在Server模式下的默认垃圾收集器。
(4)Serial Old收集器—老年代
Serial收集器的老年代版本,同样是一个单线程收集器,使用“标记-整理算法”,
(5)Parallel Old收集器—老年代
Parallel收集器的老年代版本,使用多线程和“标记-整理”算法。
(6)CMS收集器—老年代
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的老年代收集器。
在这里插入代码片新生代:主要用来存放新生的对象。新生代由Eden Space和两块相同大小的Survivor Space(通常又称为S0和S1或From和To)构成,可通过-Xmn参数来指定新生代的大小,也可通过-XX:SurvivorRatio来调整Eden Space及Survivor Space的大小。不同的GC方式会以不同的方式按此值来划分Eden Space和Survivor Space,有些GC方式还会根据运行状况来动态调整Eden、S0、S1的大小。
老年代:存放新生代中经过多次垃圾回收仍然存活的对象,例如缓存对象,新建的对象也有可能在老年代上直接分配内存。主要有两种状况(由不同的GC实现来决定):一种为大对象,可通过在启动参数上设置-XX:PretenureSizeThreshold=1024(单位为字节,默认值为0)来代表当对象超过多大时就不在新生代分配,而是直接在老年代分配,此参数在新生代采用Parallel Scavenge GC时无效,Parallel Scavenge GC会根据运行状况决定什么对象直接在老年代上分配内存;另一种为大的数组对象,且数组中无引用外部对象。
新生代和老生代因为结构划分不一样,其串行收集器算法也不一样。
新生代串行收集器
采用stop the world策略,步骤大概是:先从eden区扫描,把存活的对象拷贝到to区,如果to区放不下的对象直接拷贝到old区。再从from区扫描存活对象,如果对象存活次数超过阀值的就移到老年区,其他的移到to区。做完之后from和to区概念互换(from和to只是运行时的概念,其实就对应存活1区和存活2区)。
图形的表示如下:
回收前:
回收后:
持久代:主要存放的是Java类的类信息,与垃圾收集要收集的Java对象关系不大。方法区,主要存放Class和Meta的信息,Class在被加载的时候被放入永久代。 它和存放对象的堆区域不同,GC(Garbage Collection)不会在主程序运行期对永久代进行清理,所以如果你的应用程序会加载很多Class的话,就很可能出现PermGen space错误。
MinorGC:是指清理新生代
MajorGC:是指清理老年代(很多MajorGC是由MinorGC触发的)
FullGC:是指清理整个堆空间包括年轻代和永久代
1)JVM栈中引用的对象 ;
2)方法区中静态属性引用的对象
3)方法区中常量引用的对象
4)本地方法栈中JNI(即native方法)引用的对象。
1、System.gc()方法的调用。
2、老年代代空间不足,老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象,当执行Full GC后空间仍然不足,则抛出如下错误:Java.lang.OutOfMemoryError: Java heap space 。
3、持久代空间不足Permanet Generation中存放的为一些class的信息、常量、静态变量等数据,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation可能会被占满,在未配置为采用CMS GC的情况下也会执行Full GC。如果不足也会抛出异常。
4、CMS GC时出现promotion failed和concurrent mode failure对于采用CMS进行老年代GC的程序而言,尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况,当这两种状况出现时可能会触发Full GC。
5、统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间这是一个较为复杂的触发情况,Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象,在进行Minor GC时,做了一个判断,如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间,那么就直接触发Full GC。
6、堆中分配很大的对象 所谓大对象,是指需要大量连续内存空间的java对象,例如很长的数组,此种对象会直接进入老年代,而老年代虽然有很大的剩余空间,但是无法找到足够大的连续空间来分配给当前对象,此种情况就会触发JVM进行Full GC。
1)新生代GC(Minor GC):指发生在新生代的垃圾收集动作,因为大多数Java对象存活率都不高,所以Minor GC非常频繁,一般回收速度也比较快
2)老年代GC(Full GC):指发生在所有空间的垃圾收集动作,出现了Full GC,经常会伴随至少一次的Minor GC(但并不是绝对的)。Full GC的速度一般要比Minor GC慢上10倍以上。
上图中,刻画了Java程序运行时的堆空间,可以简述成如下2条
1.JVM中堆空间可以分成三个大区,新生代、老年代、永久代
2.新生代可以划分为三个区,Eden区,两个幸存区。
G1 收集器是jdk1.7才正式引用的商用收集器,现在已经成为jdk9默认的收集器。前面几款收集器收集的范围都是新生代或者老年代,G1进行垃圾收集的范围是整个堆内存,它采用“化整为零”的思路,把整个堆内存划分为多个大小相等的独立区域(Region),在G1收集器中还保留着新生代和老年代的概念,它们分别都是一部分Region,如下图:
每一个方块就是一个区域,每个区域可能是Eden、Survivor、老年代,每种区域的数量也不一定。JVM启动时会自动设置每个区域的大小(1M~32M,必须是2的次幂),最多可以设置2048个区域(即支持的最大堆内存为32M*2048=64G),假如设置-Xmx8g -Xms8g,则每个区域大小为8g/2048=4M。
为了在GC Roots Tracing的时候避免扫描全堆,在每个Region中,都有一个Remembered Set来实时记录该区域内的引用类型数据与其他区域数据的引用关系(在前面的几款分代收集中,新生代、老年代中也有一个Remembered Set来实时记录与其他区域的引用关系),在标记时直接参考这些引用关系就可以知道这些对象是否应该被清除,而不用扫描全堆的数据。
G1收集器可以“建立可预测的停顿时间模型”,它维护了一个列表用于记录每个Region回收的价值大小(回收后获得的空间大小以及回收所需时间的经验值),这样可以保证G1收集器在有限的时间内可以获得最大的回收效率。
如下图所示,G1收集器收集器收集过程有初始标记、并发标记、最终标记、筛选回收,和CMS收集器前几步的收集过程很相似:
① 初始标记:标记出GC Roots直接关联的对象,这个阶段速度较快,需要停止用户线程,单线程执行
② 并发标记:从GC Root开始对堆中的对象进行可达新分析,找出存活对象,这个阶段耗时较长,但可以和用户线程并发执行
③ 最终标记:修正在并发标记阶段引用户程序执行而产生变动的标记记录
④ 筛选回收:筛选回收阶段会对各个Region的回收价值和成本进行排序,根据用户所期望的GC停顿时间来指定回收计划(用最少的时间来回收包含垃圾最多的区域,这就是Garbage First的由来——第一时间清理垃圾最多的区块),这里为了提高回收效率,并没有采用和用户线程并发执行的方式,而是停顿用户线程。
适用场景:要求尽可能可控GC停顿时间;内存占用较大的应用。可以用-XX:+UseG1GC使用G1收集器,jdk9默认使用G1收集器。
1)启动类加载器---- 加载位置 :$JAVA_HOME/lib/rt.jar里所有的class或则被-Xbootclasspath参数指定的路径中。
2)扩展类加载器---- 加载位置 :加载JAVA_HOME/lib/ext目录下的或者被java.ext.dirs系统变量指定所指定的路径中所有类库。
3)应用程序类加载器----加载位置 :classpath环境变量中指定的jar包及目录中class;
4)自定义加载器----自定义的类加载器,手动加载,只需要继承自ClassLoader然后实现loadClass()方法。
双亲委派模型的工作过程是:
1)如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,向上传递。
2)所有的加载请求最终都会传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。
类加载分为以下 5 个步骤:
加载:根据查找路径找到相应的 class 文件然后导入;
检查:检查加载的 class 文件的正确性;
准备:给类中的静态变量分配内存空间;
解析:虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示,而在直接引用直接指向内存中的地址;
初始化:对静态变量和静态代码块执行初始化工作。
虚拟机的类加载机制就是把描述类的数据从Class文件(或者其他途径)加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型。
加载:1.通过一个类的全限定名获取定义此类的二进制字节流2、将这个字节流所戴晓的静态结构转化为方法区的运行时数据结构3、在内存中生成一个代表这个类的Class对象,作为方法区这个类的各种数据的访问入口。
验证:1、文件格式验证,保证输入的字节流在格式上符合Class文件的格式规范,保证输入的字节流能正确的解析,只有通过这个验证,字节流才会存储在方法区之内2、元数据验证,对类的元数据进行语义校验,保证类描述的信息符合Java语言规范。比如验证类的是否实现了父类或者接口中的方法等3、字节码验证,通过数据流和控制流的分析,确保类的方法符合逻辑,不会在运行时对虚拟机产生危害4、符号引用校验,发生在解析阶段,确保解析阶段将符号引用转化为直接饮用的正常执行。
准备:正式为类变量(static)分配内存,并设置类变量初始值(数据类型的零值),这些变量所使用的内存在方法区中分配。
解析:虚拟机将常量池内的符号引用转化为直接饮用,解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
初始化:初始化阶段才真正执行类中定义的Java代码,初始化阶段是执行类构造器方法的过程。方法(类构造器)是由编译器自动收集类中的静态变量和静态代码块合并产生的。子类和父类的初始化过程优先级为:父类类构造器->子类类构造器->父类对象构造函数->子类对象构造函数。类中静态类变量和静态代码块是按照在类中定义的顺序执行的。
(1)字节码是包含Java内部指令集、符号集以及一些辅助信息的能够被JVM识别并解释运行的符号序列。字节码内部不包含任何分隔符区分段落,且不同长度数据都会构造成n个8位字节单位表示。
(2).class里存放的就是Java程序编译后的字节码,包含了类版本信息、字段、方法、接口等描述信息以及常量池表,一组8位字节单位的字节流组成了一个字节码文件。
什么是字节码?采用字节码的最大好处是什么?
先看下java中的编译器和解释器:
Java中引入了虚拟机的概念,即在机器和编译程序之间加入了一层抽象的虚拟的机器。这台虚拟的机器在任何平台上都提供给编译程序一个的共同的接口。
编译程序只需要面向虚拟机,生成虚拟机能够理解的代码,然后由解释器来将虚拟机代码转换为特定系统的机器码执行。在Java中,这种供虚拟机理解的代码叫做 字节码(即扩展名为 .class的文件),它不面向任何特定的处理器,只面向虚拟机。
每一种平台的解释器是不同的,但是实现的虚拟机是相同的。Java源程序经过编译器编译后变成字节码,字节码由虚拟机解释执行,虚拟机将每一条要执行的字节码送给解释器,解释器将其翻译成特定机器上的机器码,然后在特定的机器上运行。这也就是解释了Java的编译与解释并存的特点。
Java源代码---->编译器---->jvm可执行的Java字节码(即虚拟指令)---->jvm---->jvm中解释器----->机器可执行的二进制机器码---->程序运行。
采用字节码的好处:
Java语言通过字节码的方式,在一定程度上解决了传统解释型语言执行效率低的问题,同时又保留了解释型语言可移植的特点。所以Java程序运行时比较高效,而且,由于字节码并不专对一种特定的机器,因此,Java程序无须重新编译便可在多种不同的计算机上运行。
JVM规定了有且仅有5中情况——对类进行主动引用,必须立即执行类的初始化。
1)、遇到new,putstatic,getstatic,invokespecial四条字节码指令的时候,如果没有进行类的初始化要立即初始化。这四条字节码指令对应的编程中的环境为:使用new关键字实例化对象,读取或设置类的静态变量,调用类的静态方法。
2)、使用java.lang.reflect包对类进行反射的时候,如果没有初始化要立即初始化。
3)、初始化一个类的时候,如果其父类没有进行初始化要先出发父类的初始化
4)、虚拟机启动的时候,main方法所在的主类会被虚拟机先初始化
5)、使用动态语言在lava.lang.invoke.MethodHandle实例最后的解析结果是REF_getdtatic,REF_putStatic,REF_invokeStatic的方法句柄,这个句柄对应的类没有被初始化需要先触发其初始化。
参数 说明 实例
-Xms 初始堆大小,默认物理内存的1/64 -Xms512M
-Xmx 最大堆大小,默认物理内存的1/4 -Xms2G
-Xmn 新生代内存大小,官方推荐为整个堆的3/8 -Xmn512M
-Xss 线程堆栈大小,jdk1.5及之后默认1M,之前默认256k -Xss512k
-XX:NewRatio=n 设置新生代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4 -XX:NewRatio=3
-XX:SurvivorRatio=n 年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:8,表示Eden:Survivor=8:1:1,一个Survivor区占整个年轻代的1/8 -XX:SurvivorRatio=8
-XX:PermSize=n 永久代初始值,默认为物理内存的1/64 -XX:PermSize=128M
-XX:MaxPermSize=n 永久代最大值,默认为物理内存的1/4 -XX:MaxPermSize=256M
-verbose:class 在控制台打印类加载信息
-verbose:gc 在控制台打印垃圾回收日志
-XX:+PrintGC 打印GC日志,内容简单
-XX:+PrintGCDetails 打印GC日志,内容详细
-XX:+PrintGCDateStamps 在GC日志中添加时间戳
-Xloggc:filename 指定gc日志路径 -Xloggc:/data/jvm/gc.log
-XX:+UseSerialGC 年轻代设置串行收集器Serial
-XX:+UseParallelGC 年轻代设置并行收集器Parallel Scavenge
-XX:ParallelGCThreads=n 设置Parallel Scavenge收集时使用的CPU数。并行收集线程数。 -XX:ParallelGCThreads=4
-XX:MaxGCPauseMillis=n 设置Parallel Scavenge回收的最大时间(毫秒) -XX:MaxGCPauseMillis=100
-XX:GCTimeRatio=n 设置Parallel Scavenge垃圾回收时间占程序运行时间的百分比。公式为1/(1+n) -XX:GCTimeRatio=19
-XX:+UseParallelOldGC 设置老年代为并行收集器ParallelOld收集器
-XX:+UseConcMarkSweepGC 设置老年代并发收集器CMS
-XX:+CMSIncrementalMode 设置CMS收集器为增量模式,适用于单CPU情况。
内存占用:程序正常运行需要的内存大小。
延迟:由于垃圾收集而引起的程序停顿时间。
吞吐量:用户程序运行时间占用户程序和垃圾收集占用总时间的比值。
基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。其中需要注意,JVM进行GC的频率很高,但因为Minor GC占用时间极短,所以对系统产生的影响不大。更值得关注的是Full GC的触发条,具体措施包括以下几个方面:
(1)不要显式调用System.gc()
调用System.gc()也仅仅是一个请求(建议)。JVM接受这个消息后,并不是立即做垃圾回收,而只是对几个垃圾回收算法做了加权,使垃圾回收操作容易发生,或提早发生,或回收较多而已。但即便这样,很多情况下它会触发Full GC,也即增加了间歇性停顿的次数。
(2)尽量减少临时对象的使用
临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,也就减少了Full GC的概率。
(3)对象不用时最好显式置为Null
一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。
(4)尽量使用StringBuffer,而不用String来累加字符串
由于String是常量,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。
(5)能用基本类型如int,long,就不用包装类Integer,Long对象
基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。
(6)尽量少用静态对象变量 :一直占用内存。
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行Full GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。