JVM

JVM 发表评论


JVM

理解jvm中的栈

一句话就是java运行在虚拟机之上,虚拟机帮java屏蔽底层的指令集,让java能够跨平台运行。
本章重点从虚拟机内存模型(运行时数据区域)入手。先看图:
这里写图片描述
这是一张比较官方的虚拟机模型图,我们今天讲的就是虚线框的那部分的栈。
栈是我们最常用的内存区域。它主要用来存放基本类型变量,局部变量以及对象的引用。例如:User user = new User();这里的user就是对象的引用也可以理解为地址,指引着虚拟机要去哪里找user这个对象。 他们的基本关系如图:
这里写图片描述
由图可知,当我们将一个对象作为方法的参数时,我们在方法中改变对象的值,也会影响到原来的对象的值,以为我们只是改了图中内存区域的值,他的指引(地址)还是一样的。同时也可以看出,栈的内存区域是连续的,有大小限制的,如果超过了就会抛出栈溢出的异常StackOverflowError。
在每个方法执行的时候,都会创建一个个的栈帧,用于保存局部变量表,操作数栈,动态链接等信息(以后都会详细讲解)。每次方法的调用都会对应着一个栈帧,因此可以解释有我们在写递归程序的时候会不小心报出栈溢出的异常,因为栈是有限,方法调用太多次导致栈帧堆满了栈,所以溢出。看下面代码:
这里写图片描述

参数-Xss128k的情况下的报错。(eclipse中设置参数:右键代码选择Run As–>Run Configurations,在Arguments栏下的VM arguments中填入参数,再Apply,再run)
这里写图片描述

每次在方法执行完毕的时候,虚拟机会自动释放掉为该栈所分配的空间,在栈中,对应着一个栈帧的出栈。虚拟机会自动分配与回收内存,因此效率比较高。
最后总结:

存放基本类型变量,局部变量,对象的引用
系统自动分配与回收内存,效率较高,快速,存取速度比堆要快;
是一块连续的内存的区域,有大小限制,如果超过了就会栈溢出;
Java会自动释放掉为该变量所分配的内存空间;
这个栈又分为java栈和本地方法栈。顾名思义,本地方法栈自然就是为本地方法提供服务的,java栈是为java服务的
OK,最后的最后就是到各位小伙伴分享转发的时候啦!
我再补充一句,JVM是每个线程私有的!就像多线程下方法里面的局部变量是不会受影响的。

栈,他在内存中是连续的空间;保存一个个的栈帧,对应一次次方法的调用;还讲到了他是保存对象的引用,那么对象存在哪里呢?我们来看看昨天的那张图。
对象就存在图中的内存区域,在JVM中,那片区域叫做堆!
由图中可以看到堆的存储结构和栈是不同的,堆在内存中并不是一块连续的区域,他是分散的(物理上是分散,但逻辑上是连续的,大家好好体会一下);虚拟机通过栈中引用的指引在堆中找到所需要的对象。
在虚拟机遇到一条new的指令的时候,经过一系列的操作过后(现在讲的话会看不懂)虚拟机就要为该新生对象分配内存空间了,那么问题来了,这么散,虚拟机要怎么知道如何分配呢?分配的方式有两种:指针碰撞和空闲列表

指针碰撞是将内存逻辑上分为两边,一边是空闲的,一边是在用的,指针指向分界点,当需要分配内存的时候只要移动指针即可。但这种只适用于内存规整的情况下,也就是刚刚说的分两边。一般用在Serial,PaeNew等垃圾收集器中,也就是堆中的新生代中。(最后一句话会在后面分几章讲,道路遥远着!)
那么空闲列表说的就是在内存不是规整的情况下,虚拟机必须维护一个列表,用于记录哪些内存是可用的,在需要进行分配的时候就从列表中找到一块足够大下的空间进行分配,并且更新列表。又要讲一句看不懂的话:该方法适用于像CMS这种基于Mark-Sweep的垃圾收集器,适用于堆中的年老区!

上两段都提到了垃圾收集器,也就是GC。写过java的都知道,java程序很少需要我们去自己释放资源,原因就是这个GC机制了。

堆分配

堆是存放对象以及数组的区域,但不是胡乱的有空间就分配的内存。堆在内存中分为了年轻代、年老代
我们先看看年轻代,这个区域又被分为了一个Eden和两个Survivor区,即伊甸园和存活区。看一张图:
这里写图片描述
从图中可以清楚的看到他们的关系是8:1。那为什么Eden占用这么多呢?因为对象都会在Eden区创建。每次只使用Eden区和一个Survivor区,当这两个区满了之后就会将还存活的对象复制到另一个空白区(MINOR GC),大家是不是在想那空间怎么会够用呢?其实年轻代的对象有98%都是朝生夕死的,所以根本不用担心不够用,这也是为什么比例是8:1而不是1:1的原因。而且!就算是不够用,我们不是还有年老代吗!
我们暂且先不说年老代,还有个问题没有解决,刚刚我们提到了复制,所以这里我们抱着求知的欲望来讲讲是怎么个复制法。首先看图:这里写图片描述
图中分为了两个部分,每次只使用其中的一部分(这里不是完全按照刚刚伊甸园和空白区的占用比例来讲,可以理解为通用版)。当这部分满了后,就会将还存活的复制到另一个区,再将这个区清空,如图:
这里写图片描述
但这种方法也有弊端,就是会浪费了一半的内存空间。但是对于年轻代这种朝生夕死的特征是一个很好的解决方法,因为只要对一半的空间进行操作,把范围大大的缩小了。
对于年老和永久区域,刚刚也说了,如果年轻代不够放了就放在年老代,还有一种情况就是对象在年轻代中存活的太久了,就会放到年老区,就像人的岁数大了就会变老年人,对象在年轻代也有岁数:每当进行一次复制回收的时候,还在年轻代中存活的对象就会加1岁,默认15岁后就到年老代。可以通过-XX:MaxTenuringThreshold=15来设置多少岁后进入年老区。
年老和永久区垃圾收集的方法都是“标记-清除-整理”,看图:
这里写图片描述
这里如果还使用年轻代的回收方法的话肯定不适用了,那边的特性是朝生夕死,而年老代存活的一般是大对象或者很难死去的对象(回收),所以不符合条件。当年老代内存不足的话就会触发垃圾收集,这个回收叫做FULL GC.默认是占用了68%后收集,可用参数-XX:CMSInitiatingOccupancyFraction=68自行设置。
收集方法中的标记这里先不说,标记好了就清除掉,最后整理成逻辑连续的区域。最后的结果:
这里写图片描述
这样可以有效的避免了内存碎片

堆GC标记

永久代是非堆内存,它又叫做方法区(一般的说法),主要存储已被加载的类信息、常量、静态变量。而该区域在java8已被删除,取而代之的是元空间,我们会在后面的章节细讲。
OK,我们继续昨天最后留下的问题,什么是标记?怎么标记?
第一个问题相信大家都知道,标记就是对一些已死的对象打上记号,方便垃圾收集器的清理。 至于怎么标记,一般有两种方法:引用计数和可达性分析。

引用计数实现起来比较简单,就是给对象添加一个引用计数器,每当有一个地方引用它时就加1,引用失效时就减1,当计数器为0的时候就标记为可回收。这种判断效率很高,但是很多主流的虚拟机并没有采用这种方法,主要是因为它很难解决几个对象之间循环引用的问题,向下图这个例子这样发生循环引用。虽然不怎么用了,但还是值得我们学习!

这里写图片描述

可达性分析的基本思路就是:通过将一些称为”GC
Roots”的对象作为起始点,从这些节点开始搜索,搜索和该节点发生直接或者间接引用关系的对象,将这些对象以链的形式组合起来,形成一张“关系网”,又叫做引用链。最后垃圾收集器就回收一些不在这张关系网上的对象。
这里写图片描述

连接GC Roots对象的object是确定还存活的对象,而右边的die obj由于和GCROOTS没有关系,所以会标记为可回收的对象。目前主流的商用虚拟机用的都是类似的方法。那什么对象才能作为“GC Roots”呢?在java中,有四种对象可以作为“GC Roots”
1:栈帧(第一章的名词)中的引用对象。(栈中的)
2:静态属性引用的对象。(方法区中的)
3:常量引用的对象。(方法区中的)
4:本地方法栈中JNI引用的对象。(本地方法栈中的)

堆二次标记

是不是被标记了就肯定会被回收呢?不知道小伙伴们记不记得Object类有一个finalize()方法,所有类都继承了Object类,因此也默认实现了这个方法。
这个方法的用途就是:在该对象被回收之前,该对象的finalize()方法会被调用。这里的回收之前指的就是被标记之后,问题就出在这里,有没有一种情况就是原本一个对象开始不再上一章所讲的“关系网”(引用链)中,但是当开发者重写了finalize()后,并且将该对象重新加入到了“关系网”中,也就是说该对象对我们还有用,不应该被回收,但是已经被标记啦,怎么办呢?
针对这个问题,虚拟机的做法是进行两次标记,即第一次标记不在“关系网”中的对象。第二次的话就要先判断该对象有没有实现finalize()方法了,如果没有实现就直接判断该对象可回收;如果实现了就会先放在一个队列中,并由虚拟机建立的一个低优先级的线程去执行它,随后就会进行第二次的小规模标记,在这次被标记的对象就会真正的被回收了。我们来看下面的代码:
这里写图片描述
大家觉得他会输出什么?最后的结果是:

我被调用啦
我还活着
我挂啦

有木有觉得很诧异,明明调用了两次同样的方法,但输出怎么不同呢?而且明明调用了两次gc()方法(这里确认是执行了gc),那怎么只进入了一次finalize()方法?
嘿嘿,其实面对同一个对象,他的finalize()方法只会被调用一次,因此第一次调用的时候会进行finalize()方法,并且成功的将该对象加入了“关系网”中,但当第二次回收的时候并不会进入,所以第二次不能将对象加入“关系网”中,导致被回收了。
图中有一行让程序睡眠一秒钟的代码,为的就是确保让低优先级的执行finalize()方法线程执行完成。那如果我们把他注释了会怎样呢?输出结果是:

我挂啦
我被调用啦
我挂啦

很奇怪吧,不过如果执行很多次的话,也会出现最开始那样的结果,但多数会是这个结果。因为我们已经说了,执行finalize()的是一个低优先级的线程,既然是一个新的线程,虽然优先级低了点,但也是和垃圾收集器并发执行的,所以垃圾收集器没必要等这个低优先级的线程执行完才继续执行。也就是说,finalize()方法不一定会在对象第一次标记后执行。用一句清晰易懂的话来说就是:虚拟机确实有调用方法的动作,但是不会确保在什么时候执行完成。因此也就出现了上面输出的结果,对象被回收之后,那个低优先级的线程才执行完。

堆设置

如何设置以及当发生堆溢出的时候怎么排查问题。先看一小段代码:
这里写图片描述
代码中使用了一个无限循环来为list添加对象,如果采用默认的堆大小的话可能要等待好久才能出现堆溢出的错误,因此我们要将其设置小一点:
-Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError,elipse中的设置方法我们在第一章讲过了,这里不多说啦。-Xms10m,意思就是堆的最小内存为10m。同理-Xmx10m的意思就是最大内存也为10m。这两个都是设置为10m,那么堆的大小就是10m。而-XX:+HeapDumpOnOutOfMemoryError指的是当发生内存溢出的时候会将当前的内存使用情况生成一个快照保存起来,但需要eclipse下载一个MAT的插件,下载方式度娘到处都是。
使用刚刚设置的参数启动程序,稍等一小会就会出现以下错误:
这里写图片描述
显示出堆溢出错误,并且生成了一个叫做java_pid4792.hprof的文件,我们刷新项目便可以看到该文件,双击打开,需要一段的加载时间。
这里写图片描述
首先可以看到的是一个饼状图,占用部分最大的便是发生溢出错误的部分,我们接着往下看 :
这里写图片描述
我们这里看看画红线的部分,这里列出一些存活的大对象,在溢出的时候一般先怀疑大对象,我们点进去:
这里写图片描述
这里列出占用内存最大的几个对象,很显然,第一个很可疑,占用率达到了94.64%!继续跟进:
这里写图片描述
发现都是test对象,因此排查的时候可以从这个方面下手。接着我们右键该对象选择Path To GC Root(在引用链上的路径),再选择exclue all phantom/weak/soft etc. reference ,结果如图:这里写图片描述
可以看到他是被List引用了,因此一直在引用链上,导致无法被回收掉,也就出现了内存溢出。

堆日志分析

但是我们知道,堆又分为了新生代,年老代。他们之间的内存怎么分配呢?新生代又分为Eden和Survivor,他们的比例大小能改变吗?其实这些都是可控的,以前没有讲到是因为就算讲了也只是讲讲而已,看不到实质性的东西。因此这章我们通过分析GC日志来一步步讲解如何细化设置堆内存。
首先我们来了解几个相关的参数:

-XX:+PrintGCDetails:用于告诉虚拟机回收垃圾的时候顺便打印日志。
-Xloggc:路径 :将打印出来的日志信息保存至指定的路径。
-Xmn10M:设置新生代的内存大小。

这里写图片描述
然后用参数-Xms20m -Xmx20m -Xmn10 -XX:+PrintGCDetails -Xloggc:d:\gc1.log启动。表示给堆分配20M,给新生代分配10M,打印GC日志,并将其输出至D盘的gc1.log文件中。运行后得到以下日志,这是第一部分:
这里写图片描述
现在我们来分析下每个部分代表的含义:
1)0.090:就是虚拟机从启动到现在经历的时间。
2)GC:指的是停顿类型(留着下一章讲)
3)PSYoungGen:发生GC的区域,这里指的是年轻代。根据收集器的种类而定。
4)7284K->1016K(9216K):该区域GC前当前区域所使用的容量–>该区域GC后已使用的容量(该区域的总容量),也就是新生代的容量。
5)7284K->6139K(19456K):整个堆GC前当前区域所使用的容量–>整个堆GC后已使用的容量(整个堆的总容量)。
6) 0.0078481:这次GC所占用的时间。

我们再来看看第二部分:
这里写图片描述
看图画红线部分,表示当前的堆中新生代可用内存的大小(一个edenh和一个Survivor视为可用内存),红色框下面则是年老区的大小,加上一共是20m,符合我们所设置的。
红色框的部分则是新生代中eden区和两个Survivor区的大小,可以看出他们的比例是8:1,如果设置为-XX:SurvivorRatio=3的话,结果如下
这里写图片描述

标记暂停阶段

当虚拟机完成两次标记后,便确认了可以回收的对象。但是,垃圾回收并不会阻塞我们程序的线程,他是与当前程序并发执行的。所以问题就出在这里,当GC线程标记好了一个对象的时候,此时我们程序的线程又将该对象重新加入了“关系网”中,当执行二次标记的时候,该对象也没有重写finalize()方法,因此回收的时候就会回收这个不该回收的对象。

虚拟机的解决方法就是在一些特定指令位置设置一些“安全点”,当程序运行到这些“安全点”的时候就会暂停所有当前运行的线程(Stop The World 所以叫STW),暂停后再找到“GC Roots”进行关系的组建,进而执行标记和清除。
这些特定的指令位置主要在:
1、循环的末尾
2、方法临返回前 / 调用方法的call指令后
3、可能抛异常的位置

    找到“GC Roots”也是要花很长的时间,然而这里又有新的解决方法,就是通过采用一个OopMap的数据结构来记录系统中存活的“GC Roots”,在类加载完成的时候,虚拟机就把对象内什么偏移量上是什么类型的数据计算出来保存在OopMap,通过解释OopMap就可以找到堆中的对象,这些对象就是GC Roots。而不需要一个一个的去判断某个内存位置的值是不是引用。这种方式也叫准确式GC。

回到最开始的问题,那个停顿类型就是刚刚所说的STW,至于有GC和Full GC之分,还有Full GC (System)。个人认为主要是Full GC时STW的时间相对GC来说时间很长,因为Full GC针对整个堆以及永久代的,因此整个GC的范围大大增加;还有就是他的回收算法就是我们之前说过的“标记–清楚–整理”,这里也会损耗一定的时间。所以我们在优化JVM的时候,减少Full GC的次数也是经常用到的办法。

年轻代收集

STW即GC时候的停顿时间,他会暂停我们程序中的所有线程。如果STW所用的时间长而且次数多的话,那么我们整个系统稳定性以及可用性将大大降低。

因此我们在必要的时候需要对虚拟机进行调优,那么调优的主要目标之一就是降低STW的时间,也就是减少Full GC的次数。那么这里我们从调优的角度来分析各个收集器的优势与不足。

首先从作用于年轻代的收集器开始(采用复制的收集算法):
Serial收集器:一个单线程收集器,在进行回收的时候,必须暂停其他所有的工作线程,直到收集结束。缺点:因为要完全暂停线程,所以用户体验不佳。但是由于新生代回收得较快,所以停顿的时间非常少,而且没有线程切换的开销,因此也简单高效。通过 -XX:+UseSerialGC参数启用。

ParNew收集器:这个是Serial收集器的多线程版本,适用于多核CPU的设备。但对于单核的设备来说,需要进行线程之间的切换,效率反而没有单线程的高。通过-XX:ParallelGCThreads参数限制收集的线程数,-XX:+UseParNewGC参数启用。

Parallel Scavenge收集器:该收集器是我们文章中的所有例子的默认年轻代收集器。他的关注点和其他的收集器不同,其他的关注点是尽可能的缩短Full GC的时间。而该收集器关注的是一个可控的吞吐量。吞吐量=运行代码的时间/(运行代码的时间+GC的时间),通过参数-XX:MaxGCPauseMillis设置最大GC的停顿时间和-XX:GCTimeRatio 设置吞吐量的大小。-XX:+UseParallelGC参数启用。主要适合在后台运算而不需要太多交互的任务。
可以通过-XX:+UseAdaptiveSizePolicy参数开启自适应调节策略,这样可以免去我们自己设置堆内存的一些细节参数,比如新生代内存大小,Eden与Survivor之间的比例等等。这个参数适合对内存手工优化存在困难的时候使用,他能监控系统当前的状态,动态的调整以达到最大的吞吐量。

这里我们只大概了解了下年轻代的收集器,下面一张图给大家总结一下:
这里写图片描述

年老代收集

老年代的存活的一般是大对象以及生命很顽强的对象,因此新生代的复制算法很明显不能适应该区域的特性,所以老年代采用的是“标记-清除-整理”算法(以前的章节有详细讨论过)。

Serila Old收集器:该收集器是Serial收集器的老年代版,同样是一个单线程的收集器,优劣势和Serial收集器一样,这里就不多说了。

Parallel Old收集器:在我们之前文章的代码例子中默认的年老代收集器,也是Parallel Scavenge收集器的老年代版本。关注点也和Parallel Scavenge收集器一样,注重系统的吞吐量,适合于CPU资源敏感的场合。

CMS(Concurrent Mark Sweep)收集器:是一种以最短停顿时间为目标的收集器。当应用尤其重视服务的响应速度,希望系统能有最短的停顿时间,该收集器非常适合。该收集器的收集过程比以往的收集器都要复杂,收集过程分为四个步骤:
初始标记
并发标记
重新标记
并发清除

先介绍下每个过程的是什么意思,再来说他是怎么达到最短停顿时间这个目标的。初始标记是需要进行STW的,但仅仅只是标记GC Roots能够直接关联的对象(并不是死掉的对象哦~),由于有OopMap的存在,因此该步骤速度非常快。如图,其中蓝色底纹的便是能够直接关联的对象。
这里写图片描述
接着就进入了第二步,并发标记。这步是不需要STW的,不需要!他和我们的主程序线程共同执行,从上一步被标记的对象开始,进行可达性分析组成“关系网”。由于不需要进行SWT,所以该步骤不会印象用户体验。既然不暂停线程,小伙伴是不是又怕回收了不该回收的对象?为了避免这个问题,因此就有了第三步。

重新标记是需要STW的,但这又有什么关系呢?重新标记只是为了修改在上一步标记中有了变动的对象。有了这一步,就不怕回收掉不该回收的对象了。而且,由于这一步只是对上一步的结果进行修改,所以STW的时间相当短,对用户的影响不大。

最后一步就是并发清除了,这一步也不需要进行STW,只是清除一些不在“关系网”上的对象而已。

讲到这里,大家应该知道了该收集器如何做到最短停顿时间了吧。通过一次短STW时间的标记和一次不需要STW的标记,大大缩下来第三步标记的范围(只需要修改就好了),第四步不需要STW。

看上去很完美,但还是有他的缺陷:大量使用了并发操作,因此会占用一部分CPU的资源,导致吞吐量下降;当在并发清除垃圾的时候,也就是第四步的时候,他是有当前主线程并发执行的,因此他在回收的时候,我们的主线程又会产生新的垃圾,而这些垃圾在这次回收过程已经回收不了了,只能等待下一次回收了。这些垃圾又叫做“浮动垃圾”。

G1收集器

先讲讲G1收集器的特点,他也是个多线程的收集器,能够充分利用多个CPU进行工作,收集方式也与CMS收集器类似,因此不会有太久的停顿。

虽然回收的范围是整个堆,但还是有分代回收的回收方式。在年轻代依然采用复制算法;年老代也同样采用“标记-清除-整理”算法。但是,新生代与老年代在堆内存中的布局就和以往的收集器有着很大的区别:G1将整个堆分成了一个个大小相等的独立区域,叫做region。其中依然保存着新生代和年老的概念,如图:

这里写图片描述
是不是和之前章节看到的不同(这是对内存空间图,不要和垃圾回收的图弄混了),以往只是简单的分区域,而这里是将整个堆分成多个大小相等的区域。

他的回收过程也分为四个部分:
初始标记
并发标记
最终标记
筛选回收

大家是不是觉得很熟悉!上面我们也说过了,和CMS收集器类似,初始标记需要STW;并发标记不需要;最终标记就是做一些小修改,需要STW;而筛选回收则有些不同,在众多的region中,每个region可回收的空间各不相同,但是回收所消耗的时间是需要控制的,不能太长,因此G1就会筛选出一些可回收空间比较大的region进行回收,这就是G1的优先回收机制。这也是保证了G1收集器能在有限的时间内能够获得最高回收效率的原因。

通过-XX:MaxGCPauseMills=50毫秒设置有限的收集时间

每个region之间的对象引用通过remembered set来维护,每个region都有一个remembered set,remembered set中包含了引用当前region中对象的region对象的指针。虚拟机正是通过这个remembered set去避免对整个堆进行扫描来确认可回收的对象。

到此,所有的收集器都已经讲完了,但是很重要的一点:每个收集器是不能随意进行组合使用的!这里我列出一个搭配使用的表格提供大家参考使用:
这里写图片描述

可视化分析

我们今天要讲工具位于JDK目录的bin目录下,大家可以发现该目录下有很多可执行文件,这里都是JDK为我们提供用于分析内存的一些工具。我们重点看看jconsole.exe,JAVA监视与管理控制台。

先运行以下程序:
这里写图片描述
再双击运行可视化工具,这里会让你选择要监控的程序,我们选择刚刚运行的程序。结果如图:
这里写图片描述
该页面只是一个概览页面,我们可以点进去上方导航栏的内存页,进去后我们可查看内存中各部分的使用情况图表,这里我们选择Eden区的查看。
这里写图片描述
可看到内存使用呈锯齿波状态,因为我们在循环中不断的产生新对象,而新对象又在Eden区中创建,所以内存使用会不断增加,当达到所设定的最大值后就会进行内存的回收,由于每个新生的对象都被存入到了List中,因此都不属于垃圾对象(因为处于关系网中),所以就要复制到另一个Survivor中,如果另一个Survivor区也满了,就会复制到年老区了。可查看上图右下角绿色图,在运行中会动态更新的,变化情况和我刚刚说的是一样的。

当我们使用多线程的时候,会经常出现程序一直运行不会停止的情况,有可能出现死锁,有可能出现了死循环,可以通过该工具检测出来,先运行以下程序:
这里写图片描述
再点击导航栏上的线程进入线程查看页:
这里写图片描述
进入后页面长这个样子,看下方红色标记部分,根据我们刚刚执行的代码来看,代码开启了一个线程,作用就是执行死循环,线程的名字为默认的“Thread-0”。因为有了死循环,所以程序无法正常退出,查看堆栈跟踪,发现程序停在Test类的第14行,查看代码可发现那里是个死循环。注意:这里只是个测试例子,因此线程的名字用的是默认的,在实际环境中应为每个线程命名,在跟踪调试的过程中会大大减少工作量。

接下来我们来测试死锁的情况,运行以下代码:
这里写图片描述
代码中线程1先申请obj1,再申请obj2;线程2先申请obj2,再申请obj1。如果执行次数多了就会出现死锁,我们依然来看线程的监控台:
这里写图片描述
可以看出来,这么多的线程都处于等待中,不能正常退出,我们随机点一个查看,可以看到他的状态是BLOCKED。他需要的锁被线程31所持有。我们再看看31的线程(就不发图了),可以看到他需要的锁被线程30所持有。那么我们再看看30的线程,可以发现,30线程所需要的锁被31号线程所持有。他们互相等待,互相不释放,最终导致死锁,也导致后面那么多的线程处于BLOCKED状态。

这个可视化的工具我们就先讲这么多吧。从内存到线程,是我们在实际环境中不管是优化还是编码都会经常遇到的问题。

小结

内存基本分为JAVA栈、本地方法栈、堆和方法区。

首先栈存放的是基本类型变量,局部变量,和对象的引用,他在内存中是一块连续的区域,有大小限制,是由系统自动分配的,因此它的读写速度比较快,而且会自动释放掉为该变量所分配的内存空间;还有一点就是他还存放线程调用方法时存储局部变量表,操作,方法出口等与方法执行相关的信息。

堆的话是存放对象和数组;在运行时动态分配内存(比如 new()),较慢,但灵活;是不连续的内存区域,在发出申请的时候,系统首先会遍历一个存有空闲地址节点的链表,找到第一个满足申请大小的节点,将他从链表删除,并分配给申请者,如果有多,则将多出来的加入链表;由Java虚拟机的自动垃圾回收器来管理。分为一个Eden区和两个Survivor区。

方法区主要存放静态变量,常量,全局变量。他的大小不必是固定的,jvm可以根据应用的需要动态调整,同样方法区也不必是连续的。方法区可以在堆(甚至是虚拟机自己的堆)中分配。jvm可以允许用户和程序指定方法区的初始大小,最小和最大尺寸。因为方法区是被所有线程共享的,所以必须考虑数据的线程安全。假如两个线程都在试图找一个类,在该类还没有被加载的情况下,只应该有一个线程去加载,而另一个线程需要等待。

本地方法栈则是为执行Native方法服务,但这个在不同JVM内有不同的内部实现,比如在HotSpot JVM中Java虚拟机栈和本地方法栈被实现为同一个栈区。

对于收集方法来说一般有两种,“复制”和“标记-清除-整理”。“复制”算法需要留有部分空间用于复制后的存储,适用于朝生夕死的对象;“标记-清除-整理”适用于年老代,清除后形成逻辑上连续的区域,避免了内存碎片。

对象被回收之前都要先被标记为可回收的对象,一般有引用计数和可达性分析法。JAVA采用的则是可达性分析,从“GC Roots”开始组建一张张的关系网,不在关系网上的就会被清除。标记有两次,因为被标记后还可能会执行finalize()方法。“GC Roots”被记录在OopMap中,能够让虚拟机快速的得到他们,不用遍历整个堆来寻找“GC Roots””了。

回收的时候需要暂停程序的所有线程,这个过程叫做STW,我们的程序需要优化的时候,缩短STW也是优化的一部分。

各种收集器都为缩短STW的时间提供了不同的策略,并行的串行的,作用于年轻代的,作用于年老代的,还有作用于整个堆的。各有各的优劣势,需要搭配使用,不能随意组合。

上一篇:
下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

昵称 *