读-深入理解Java虚拟机(1-2章)随笔

  笔者花了一个星期的晚上时间看完了前面三章,由于之前在其他博客看过JVM的东西,所以看起来比较快。第一章:走近Java1.1 JDK、JRE定义以及关系  Java技术体系包括五个部分
  • Java程序设计语言
  • 各种硬件平台上的Java虚拟机
  • Class文件格式
  • Java API类库
  • 来自商业机构和开源社区的第三方类库
  •   JDK(Java Developmenet kit)  :包含的部分有Java程序设计语言、Java虚拟机、Java API类库这三部分,JDK又称是用于支持Java程序开发的最小环境;  JRE(Java RunTime Environment):属于JDK的一部分,它包含了Java虚拟机和Java核心类库(即Java API类库的子集);  关系:  两种解释方式,同一个意思
  • JDK包含JRE,JDK中编译器、调试器和其他工具JRE是没有的。如果需要编译.java文件,是需要JDK的支持的。
  • JDK可以看作是JRE的一个超集,提供了更多的工具,比如编译器、各种诊断工具等
  • 1.2 Java技术体系可划分为四个  
  • Java Card:支持一些Java小程序(Applets)运行在小内存设备(如智能卡)上的平台。——关于Applets之前有在面试一家公司时了解到,他们是用作于ERP系统的开发;
  • Java ME:支持Java程序运行在移动终端(手机、PDA)上的平台,对于Java API有所精简,并加入了针对移动终端的支持,之前叫J2ME。——09年的之前时候,每个人的非智能手机上应该都接触过Java开发的手机游戏,打开游戏时会第一个显示出Java,和一杯咖啡。关于Java为什么是显示的一杯咖啡呢,是因为Java的名字就是印度尼西亚一个岛的名称,就叫爪哇岛,且岛上盛产咖啡;
  • Java EE:支持使用多层架构的企业应用(如ERP、CRM应用)的Java平台,除了提供Java SE API外,还对其做了大量的扩充并提供了相关的部署支持,以前叫J2EE。——就是我们熟知的网站后端项目,扩充就是javax.*包下的类。现在流行前后端分离,所以完全可以舍弃JSP了,后端开发人员只需提供相应的JSON数据与前端对接就够了,这也是以后项目的必然发展趋势。
  • 1.3 Java虚拟机的品种(服务器端主要的)
  • Classic VM——世界上第一款商用Java虚拟机。毕竟是开国元勋,纪念还是要的
  • HotSpot VM——它是SunJDK和OpenJDK自带的虚拟机,也是目前使用范围最广的Java虚拟机。打开cmd,输入java -version,会显示如下图的信息(前提是你装的是1.8版本的)。关于SunJDK和OpenJDK其实就是一个不开源,一个开源,基本功能都差不多。
  • JRockit / J9——一个是BEA公司的,一个属于IBM公司,都说是 "世界上速度最快的Java虚拟机"。可是默认的虚拟机还是HotSpot,淘宝就基于OpenJDK开发出了属于自己的TaoBao VM。
  • 图1.1  java -version示意图1.4 展望Java技术未来之多核并行2. Java内存区域与内存溢出异常2.1 运行时数据区域  以下是《Java虚拟机规范(JavaSE 7版)》的规定,Java虚拟机所管理的内存将会包括以下几个运行时数据区域。左边暗粉色区域为线程共享区域,右边为线程私有的。  图2.1 Java虚拟机运行时数据区2.1.1  程序计数器  程序计数器是一块较小的内存空间,它可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里面(仅是概念模型,各种虚拟机可能会通过一些更高效的方式去实现),字节码解释工作时就是通过改变这个计数器的值来选去下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程回复等基础功能都需要以来这个计数器来完成。  由于Java虚拟机的多线程是通过现场曾轮流切换并分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器(对于多核处理器是一个内核)都会执行一条线程中的指令。因此,为了线程切换后能恢复到正确的位置,每条线程都需要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存。
    2.1.2  Java虚拟机栈  Java虚拟机栈中还有着局部变量表部分,局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、doublle)、对象引用(reference类型,它不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。  其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot),其余的数据类型只占用1个。局部变量表所需要的内存空间是完全确定的,在方法运行期间不会改变局部变量表的大小。  在Java虚拟机规范中,对这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常;如果虚拟机栈可以动态扩展(当前大部分的Java虚拟机都可动态扩展,只不过Java虚拟机规范中也允许固定长度的虚拟机栈)如果扩展是无法申请到足够的内存,就会抛出OOME异常。OutOfMemoryError后文就简称为OOME了。2.1.3  本地方法栈   本地方法栈(Native Method Stack)与虚拟机栈所发挥的作用是非常相似的,它们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由的实现它。甚至有的虚拟机(譬如Sun HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowError和OOME异常。2.1.4 Java堆  对于大多数应用来说,Java堆(Java Heap)是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存。这一点Java虚拟机规范的描述是:所有的对象实例以及数组都要在堆上分配,但是随着JIT编译器的发展与逃逸分析技术逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化发生,所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。  Java堆是垃圾收集器管理的主要区域,因此很多时候也被称做“GC堆”(Garbage Collected Heap)。从内存回收的角度来看,由于现在收集器基本都采用分代收集算法,所以Java堆中还可以细分为:新生代和老年代;再细致一点的有Eden空间、From Survivor 空间、To Survivor 空间等。从内存分配的角度来看,线程共享Java堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB敲黑板:后面常提)。不过无论如何划分,都与存放内容无关,无论哪个区域,存储的都仍然是对象实例,将进一步划分的目的是为了更好地回收内存,或者更快的分配内存。  根据Java虚拟机规范的规定,Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可,就像我们的磁盘空间一样。在实现时,既可以实现成固定大小的,也可以是可扩展的,不过当前主流的虚拟机都是按照可扩展来实现的(通过-Xmx和-Xms控制)。如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,将会抛出OOME异常。关于参数我们可以看看安装的Eclipse安装目录下eclipse配置信息里面的参数,-vmargs以下的是虚拟机配置参数。如下图图2.2 eclipse配置信息  使用JDK1.8版本,使用G1垃圾收集器,使用字符串去重机制,最小堆内存256M,最大堆内存1024M,关闭使用偏向锁。关于垃圾收集器第三章会重点介绍,堆内存的话一般weblogic和tomcat服务器优化是把最小和最大堆内存写成一样的,避免了扩展时产生不必要的内存碎片。偏向锁的话,在Java并发编程的艺术中有详细介绍,这里就不BB了。2.1.5 方法区  方法区(Method Area)与Java堆一样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即使编译器后的代码等数据。虽然Java虚拟机规范把方法区描述为对的一个逻辑部分,但是它却有一个别名叫做Nonn-Heap(非堆),目的应该是与Java堆区分开来。  对于习惯在HotSpot虚拟机上开发、部署程序的开发者来说,很多人都更愿意把方法区成为“永久代”(Permanent Generation)再敲黑板:JDK1.8后移除了永久代,本质上两者并不等价,仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区,或者说使用永久代来实现方法区而已,这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存,能够省去专门为方法区编写内存管理代码的工作。对于其他虚拟机(如BAE JRockit、IBM J9等)来说是不存在永久代的概念的。原则上,如何实现方法区属于虚拟机实现细节,不受虚拟机规范约束,但使用永久代来实现方法区,并不是一个好主意,这样更容易遇到内存溢出问题(永久代有-XX:MaxPermSize的上限,其他两个虚拟机只要没有触碰到进程可用内存的上限,例如32为系统中的4GB,就不会出现问题),而且有极少数方法(例如String.intern())会因为这个原因导致不同虚拟机下有不同的表现。因此,对于HotSpot虚拟机,根据官方发布的路线图信息,现在也有放弃永久代并逐渐改为采用Native Memory来实现方法区的规划了,在JDK1.7的HotSpot中,已经将字符串常量池从永久代中移除了。  Java虚拟机规范对方法区的限制非常宽松,除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外,还可以选择不实现垃圾手机。相对而言,垃圾收集行为在这区域是比较少出现的,但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载,一般来说,这个区域的回收“成绩”比较难以令人满意,尤其是类型的卸载,条件相当苛刻,但是这部分区域的回收确实是必要的。在Sun公司的BUG列表中,曾出现过的若干个严重的BUG就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。2.1.6 运行时常量池   运行时常量池(Runtime  Pool)是方法区的一部分。Class文件中除了有类的版本,字段,方法,接口等描述信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后进入方法区的运行时常量池中存放。2.1.7 直接内存  直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范定义中的内存区域。但那是这部分内存也被频繁地使用,而且也可能异常能导致OOME异常出现,所以放在一起讲。  JDK1.4中新加入了NIO(New Input / Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的 I / O 方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java堆和Native堆中来回复制数据。关于NIO以及NIO2(也叫AIO),非阻塞IO / 异步非阻塞IO,以后再进行讲解。  显然本机直接内存的分配不会受到Java堆大小的限制,但是,既然是内存,肯定还是会受到本机总内存(包括RAM以及SWAP区挥着分页文件)大小以及处理器寻址空间的限制。服务器管理员在配置虚拟机参数是,会根据实际内存设置 -Xmx等参数信息,但经常忽略直接内存,值得各个区域综合大于物理内存限制(包括物理的和操作系统级的限制),从而导致动态扩展时出现OOME异常。说白了就是你本机的内存,不属于Java虚拟机规范里面的东西,毕竟程序运行的时候,不止你Java虚拟机在运行。2.2  关于HotSpot虚拟机2.2.1 对象的创建  Java中对象的创建方式有4种,这里只是讲用new关键字来创建时的状况。虚拟机遇到一条new指令时,首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程。关于类加载过程在第七章,有关BootStrapClassLoader相关类的介绍,和双亲委派机制是啥,一句话:在执行类加载时,会先去其父类可不可以解决,可以,就让父类来做,没有才轮到你。有关类加载,在之后的篇幅将进行讲解。
  • 指针碰撞:假设Java堆中内存是绝对规整的,所有内存都放在一遍,空闲的内存放在另一边,中间放一个指针作为分解点的指示器,那所分配内存仅仅是把那个指针向空闲空间那边挪一段与对象大小相等的距离。
  • 空闲列表因为堆内存在物理上是不连续的,而在逻辑上是连续的。当虚拟机在给对象在堆中分配内存时,会出现图2.3的状况。为了让对象能够在堆中能分到内存,虚拟机必须维护一个列表,记录上哪些内存块是可以用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录。
  •   选择哪种分配方式,由Java堆是否规整决定,而Java堆是否规整由垃圾收集器是否带有压缩整理功能决定。对象创建在虚拟机中是非常频繁的行为,在并发的情况下,很可能线程正在创建A对象,还没来的及修改指针位置,对象B又用了原来的指针来分配内存。这种情况下有两种解决方案,
  •   用CAS操作;
  •   用TLAB,第二种就是把内存分配的动作按照流程划分不同的空间之中进行,即每个线程在Java堆中预定一块内存(这不就占座吗),哪个线程要分配线程,就在那个线程的TLAB上分配。可以设置参数-XX:+UserTLAB参数来设定(使用),-XX:-UserTLAB(禁用)
  •    内存分分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头),如果使用TLAB,这一工作可以提前至TLAB分配时进行。这一步操作保证的对象的实例字段在Java代码中可以不不赋初始值就直接使用,程序可以访问到这些字段的对应的零值(null、0)。   图2.3 Java堆中内存图2.2.2 对象的布局  在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头、实例数据、对齐填充。
  •  对象头:
    1.   MarkWord:用于存储对象自身的运行时数据。根据你使用的计算机是32bit还是64bit,这里以32bit举例。就是32个0和1,前面25bit是对象的哈希码,4bit存年龄,1bit是否是偏向锁,2bit锁标记位;运行时又不一样了,百度一下
    2.      类型指针: 即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针,也就 是,查找对象的元数据信息并不一定要经过对象本身。另外,如果对象是Java数组,那在对象头中必须还有一块用于记录数组长度的数据,因为虚拟机可以通过普通Java对象的元数据信息确定对象的大小,但是从数组的元数据中无法确定数组的大小。
  •  实例数据:  
  •         对象真正存储的有效信息,也是在程序代码中所定义的各种类型的字段内容。无论是父类继承下来的,还是子类中定义的,都要记录下来。HotSpot虚拟机默认的分配策略是相同宽度的字段分配到一起(longs/doubles、shorts/chars.....为什么记long占8个字节/double占8字节,char占2字节...)。满足这个前提下,在父类 中定义的变量会出现在子类之前。如果CompactFields参数值为true,那么子类中较窄的变量也可能会插入到父类变量的空隙中。
  •    对齐填充:
  •         并不是必然存在的,没有特别含义,仅仅是起着站位符的作用,由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍,就是对象的大小必须是8字节整数倍。而对象头部分正好是8字节的倍数(1或2倍),so,当对象实例数据部分没有对齐时,就需要通过对齐填充来补全。2.2.3 对象的访问定位  Java程序需要通过站上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用怎么来实现,不同  虚拟机有不同实现,目前主流的访问方式有两种,句柄和直接指针。
  •   句柄:使用句柄(Handle)访问,在Java堆中会划分一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各自的具体地址信息,如图2.4。
  • 图 2.4 通过句柄访问对象
  •     指针:使用指针,Java堆对象的布局就必须考虑如何防止访问类型数据的相关信息,而reference中存储的直接就是对象地址,如图2.5所示。
  •     2.5  通过直接指针访问对象  HotSpot采用第二种方式实现。 

    相关内容推荐