走进JVM,浅水也能捉鱼

标签: 程序员 JVM | 发表时间:2012-12-20 09:52 | 作者:
出处:http://blog.jobbole.com

来源:  lrysir 的博客

这不是一篇描述jvm是什么的文章,也不介绍jvm跨平台的特性,也不是讲述jvm安全特性的文章,更不是讲解jvm指令操作,数据运算的文章,本文重点讲述类型的生命周期。

类型的生命周期涉及到:类的装载、jvm体系结构、垃圾回收机制。

为什么要讲jvm体系结构?因为类的装载和垃圾回收机制都和jvm体系结构息息相关。

那么什么是jvm体系结构呢?

走进JVM,浅水也能捉鱼

当jvm运行起来的时候,它会向系统申请一片内存区(不同的jvm实现可能不同,有些可以使用虚拟内存),将这块内存分出一部分存储许多东西,例如:程序创建的对象,传递给方法的参数,返回值,局部变量等等,我们将这块内存称之为运行时数据区,运行时数据区可以划分成方法区、堆、java栈、pc寄存器、本地方法栈。看到上面这幅图,和这些解说你可能大概的明白jvm体系是个啥样子,但是你或许还不了解运行时数据区里面方法区等用来干嘛的。

方法区:当虚拟机装载一个class文件的时候,它会从这个class文件包含的二进制数据中解析类型信息,然后将这些类型信息放到方法区中。因为方法区是被所有线程共享的,所以必须考虑数据的线程安全。假如两个线程都在试图找lava的类,在lava类还没有被加载的情况下,只应该有一个线程去加载,而另一个线程等待。

PC寄存器:每个新线程产生都将得到自己的pc寄存器以及一个java栈帧。

:存放程序运行时产生的所有对象。堆是一个线程共享的内存区,所以我们写多线程程序的时候需要考虑并发。

Java栈:java栈由许多栈帧组成的,如图,当一个线程调用java方法时,虚拟机压入一个新的栈帧到java栈中,当方法返回的时候,这个栈帧被从java栈弹出并被抛弃。 走进JVM,浅水也能捉鱼

那么现在你应该可以想象到一些jvm是怎么工作的了,是不是应该接着讲具体工作原理了呢?。但是不急,先了解下类的装载机制。

了解类的装载机制之前先了解jvm里面的类装载器:BootstrapLoader、ExtClassLoader、AppClassLoader;ExtClassLoader(负责装载jre下面的rt.jar,charsets.jar)和AppClassLoader(负责转载classpath下面的类包)是ClassLoader(抽象类)的子类;

BootstrapLoader(负责装载jre核心类库)是根装载器,是c/c++写的,在java里面看不到它。

这三个类装载器存在父子关系,根装载器是ExtClassLoader父装载器,ExtClassLoader是AppClassLoader父装载器;

Jvm中类的装载也是安全机制沙箱模型的第一道门槛。Java装载类使用双亲委派模式即全盘负责委托机制。好现在让我们了解装载大概流程。

当装载一个类的时候,若是由用户指定一个类装载器装载的话,那么那个类装载器会先委派给父类装载器,一直委派到根装载器,如果装载的是一个java.lang.String,由于它是核心类库的而且已经被装载过了,那么就会直接返回一个class对象,那么如果是一个根装载器找不到的类呢?接着就会交给子类(下一级父类)装载器,如果还是没有找到类文件,接着就会由之前用户指定的那个类装载器装载。(这里没有说明装载超类的过程,请勿疏忽)。

如果是有人恶意的写了一个基础类java.lang.String,那么会影响虚拟机吗?不会因为这个类最终会交由根装载器装载,而根装载器只会去jre核心类库加载,最终返回的class类型并不是用户写的String,而且系统自带的String,也就是说用户写String永远不会被加载。

了解了类装载器是怎么工作了之后,我们也需要了解下class文件格式;

TheClassFileStructure
ClassFile{
u4magic;//魔数
u2minor_version;//class次版本号
u2major_version;//class主版本号
u2constant_pool_count;//常量池计数
cp_infoconstant_pool[constant_pool_count-1];//常量池
u2access_flags;//修饰符
u2this_class;//常量池索引
u2interfaces_count;
u2interfaces[interfaces_count];
u2fields_count;
field_infofields[fields_count];
u2methods_count;
method_infomethods[methods_count];
u2attributes_count;
attribute_infoattributes[attrributes_count];
}

我们需要了解的有很多,但是我们难以理解的就是cp_infoconstant_pool常量池。

一个常量池里面有很多表:

CONSTANT_Utf8 UTF-8编码的Unicode字符串

CONSTANT_Integer int类型的字面值

CONSTANT_Float float类型的字面值

CONSTANT_Long long类型的字面值

CONSTANT_Double double类型的字面值

CONSTANT_Class 对一个类或接口的符号引用

CONSTANT_String String类型字面值的引用

CONSTANT_Field ref对一个字段的符号引用

CONSTANT_Method ref对一个类中方法的符号引用

CONSTANT_InterfaceMethod ref对一个接口中方法的符号引用

CONSTANT_NameAndType 对一个字段或方法的部分符号引用

这些表结构我也不解释了,如果对class文件不够了解也没什么关系,知道个大概也行。那么我们了解了jvm体系,类装载器工作流程,那么我们细看下类装载器工作中,jvm运行时数据区的变化,方法区里面的结构等等。

在类装载的过程中,每一个类装载器都会在方法区里面形成一张表,这张表记载着该装载器和对应的类的权限定名。没这么一张表就形成了jvm内部的命名空间。同时在方法区里面还该类的常量池等信息。

那么说到这些,其实这个过程还是很模糊,而且很多知识也落下了,那么我们现在看一个详细一点的装载过程。

当装载一个普通的类的时候,即调用类装载器的loadClass方法,如果希望装载的类还没有被装载到命名空间,那么jvm会传递一个该类型的全限定名给类装载器,也就是常量池CONSTANT_Class_info(该表存储着父类、类装载器等信息)入口的装载器,来试图装载被引用的类型,如果发起引用的类型是被jvm装载器定义的,那么由jvm类装载器装载,否则由用户自定义装载器装载,那么一旦被引用的类型被装载了,jvm仔细检查它的二进制数据,如果类是是一个类,并且不是java.lang.Object。jvm根据数据得到它的全限定名进行装载(递归的应用了)这个过程还需要递归超接口。

装载差不多讲完了,一个完整的过程是:装载连接——初始化。

那么连接和初始化就一带而过了,重点放在垃圾回收。

连接的过程主要是验证(确认类型符合java语言的语义,并且它不会危及虚拟机的完整性)、准备(java虚拟机为类变量分配内存,设计默认初始值)、解析(在类型的常量池中寻找类、接口、字段和方法的符合引用,把这些符号引用替换成直接引用的过程)。

初始化的时候,如果类存在直接超类,且超类还没有被初始化,就先初始化直接超类。初始化接口并不需要初始化它的父接口。

补充:

Jvm当运行某个方法的时候,先把这个方法压入java栈中,里面包含局部变量等信息,那么对象放入哪里呢?压入栈的是对象的引用,即变量,所有的对象都存储在堆中。

为什么要把对象放入堆,把变量之类的数据放入栈呢?说白了,对象太大了,存入栈中运算麻烦。(当然标准的回答不是这样的,我这里仅仅是说明实质)

了解了这么一个过程之后,我们必然要了解垃圾回收机制了。

基本回收算法

1. 引用计数:比较古老的回收算法。原理是此对象有一个引用,即增加一个计数,删除一个引用则减少一个计数。垃圾回收时,只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。

2. 标记-清除:此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除。此算法需要暂停整个应用,同时,会产生内存碎片。

3. 复制:此算法把内存空间划为两个相等的区域,每次只使用其中一个区域。垃圾回收时,遍历当前使用区域,把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象,因此复制成本比较小,同时复制过去以后还能进行相应的内存整理,不过出现碎片问题。当然,此算法的缺点也是很明显的,就是需要两倍内存空间。

4. 标记-整理:此算法结合了标记-清除和复制两个算法的优点。也是分两阶段,第一阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,把清除未标记对象并且把存活对象压缩到堆的其中一块,按顺序排放。此算法避免了标记-清除的碎片问题,同时也避免了复制算法的空间问题。

5. 增量收集:实施垃圾回收算法,即:在应用进行的同时进行垃圾回收。

6. 分代:基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代,对不同生命周期的对象使用不同的算法(上述方式中的一个)进行回收。现在的垃圾回收器(从J2SE1.2开始)都是使用此算法的。

相关文章

相关 [jvm] 推荐:

JVM研究

- - 开源软件 - ITeye博客
每天接客户的电话都是战战兢兢的,生怕再出什么幺蛾子了. 我想Java做的久一点的都有这样的经历,那这些问题的最终根结是在哪呢. JVM全称是Java Virtual Machine,Java虚拟机,也就是在计算机上再虚拟一个计算机,这和我们使用 VMWare不一样,那个虚拟的东西你是可以看到的,这个JVM你是看不到的,它存在内存中.

jvm调优

- - 互联网 - ITeye博客
printf "%x\n" 21742  找到耗时最长的进程. jstack pid | grep 54ee  定位某个类的方法. jstack 10535|grep -A 10 2a1d (最后十行). jmap 查询pid 内存线程. 附:TOP命令中需要关注的值:. (1)load average:此值反映了任务队列的平均长度;如果此值超过了CPU数量,则表示当前CPU数量不足以处理任务,负载过高.

学习JVM的References

- LightingMan - 淘宝JAVA中间件团队博客
本blog中列举了我学习JVM的references,会不断的更新,为了避免版权问题,就不在blog上提供references的下载了,感兴趣的同学可自行下载或购买,:). |— [ Hotspot GC论文 ]. |— [ 其他JVM GC ]. |— Linux内核源代码情景分析. |— Linux 内核中断内幕.

深入理解JVM

- 小伟 - ITeye论坛最新讨论
1   Java技术与Java虚拟机. 说起Java,人们首先想到的是Java编程语言,然而事实上,Java是一种技术,它由四方面组成: Java编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API). 图1   Java四个方面的关系. 运行期环境代表着Java平台,开发人员编写Java代码(.java文件),然后将之编译成字节码(.class文件).

jvm垃圾回收

- Cano - 淘宝共享数据平台 tbdata.org
在jvm中堆空间划分为三个代:年轻代(Young Generation)、年老代(Old Generation)和永久代(Permanent Generation). 年轻代和年老代是存储动态产生的对象. 永久带主要是存储的是java的类信息,包括解析得到的方法、属性、字段等等. 我们这里讨论的垃圾回收主要是针对年轻代和年老代.

JVM内存分配

- - 移动开发 - ITeye博客
计算机内存,它算是CPU与计算机打交道最频繁的区域,所有数据都是先经过硬盘至内存,然后由CPU再从内存中获取数据进行处理,又将数据保存到内存,通过分页或分片技术将内存中的数据再flush至硬盘. 那JVM的内存结构到底是如何呢. JVM做为一个运行在操作系统上,但又独立于os运行的平台,它的内存至少应该包括象寄存器、堆栈等区域.

Azul开源Zing Jvm

- - InfoQ cn
4月末,继Zing 5.2 之后,. Azul Systems宣布他们将无停顿(pauseless )的 Zing JVM提供给开源软件开发者和项目,以供开发和测试. Azul Systems 工程部副总裁和合作创始人Shyam Pillalamarri向InfoQ说明道:. 我们的部署很大一部分基于开源组件,所以我们认为:“假设我们不能将一些有价值的东西免费提供给开源项目贡献者,他们将一直受限于从Java虚拟机(JVM)视角所看到的内容”,他们将不会考虑额外的用例,或者选择其他能解决了所有内存或扩展性问题、类似Zing的系统.

JVM参数设置

- - 企业架构 - ITeye博客
-Xms768m -Xmx1280m  jvm堆的最小值和最大值设置,一般设成相同值,避免频繁分配堆空间. -XX:NewSize=128m -XX:MaxNewSize=128m  年轻代最小值和最大值设置(年轻代设定了,年老代也就定了),也可以用参数-XX:NewRatio=4,年老代和年轻代的大小比,这里128m有点小了,官方建议的是heap的3/8,差不多280m.

JVM的DirectMemory设置

- - 编程语言 - ITeye博客
原文: http://dongliu.net/post/504141. 几台服务器的JVM占用内存总是持续增长,大大超过-Xmx设定的值,服务器物理内存几乎被耗尽. 使用jmap查看JVM的内存使用,发现jvm的堆大小完全在-Xmx参数设定的范围之内,那问题只能处在别的地方了. JVM除了堆内存之外,就只有栈内存和DirectMemory了.

JVM调优总结

- - Java - 编程语言 - ITeye博客
JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制. 32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制. 我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m.