Java 内存区域分析

  Java虚拟机在执行的过程中会将物理内存划分为几个区域来进行管理,这些区域都有特定用途和生命周期。Java虚拟机规范中提到,有以下6个部分组成:

1:寄存器(PC Register)

  Java虚拟机的多线程是通过轮流切换分配处理器执行时间来实现的,在任何一个时间点上,一个处理器只能执行一个线程中的指令,其余线程中断状态。因此为了记录每个线程当前所执行的指令,每个线程都会拥有一个独立的PC寄存器,用于保存线程执行状态。而且寄存器互不影响,类似这样的内存空间也叫做“线程私有”内存。

  特别的,如果执行的方法是native方法,寄存器是不确定的(undefined),如果是Java方法,寄存器保存的是当前字节码指令地址。PC寄存器的容量至少应当能保存一个 returnAddress 类型的数据或者一个与平台相关的本地指针的值。所以在计算内存使用的时候,这一部分可以忽略不计。

2:虚拟机栈(Java Virtual Machine Stacks)

  虚拟机栈也是线程私有的,与线程生命周期一致,创建的时候分配,终止的时候回收。在内存中以帧的形式存储,用于保存线程的局部变量表,局部计算结果,一个方法开始执行到返回结果,对于栈来说就是一个帧入栈和出栈的过程。其中局部变量表中包含了基本数据类型和引用对象(对象地址指针,字节码地址等等)

  在Java虚拟机规范第一版中,Java虚拟机栈也被直接称作Java栈,这个规范允许要么以固定尺寸来分配空间或者能动态扩展。如果栈大小是固定的,创建栈的时候,每一个Java虚拟机栈大小都可以独立选定。即通过参数决定栈大小或者最大最小值,内存可不要求连续。Java虚拟机的栈可以分配于更底层语言中的堆中。

  Java虚拟机栈上操作会有两个异常需要考虑,一是线程计算请求的栈深度(容量)超过虚拟机所允许的深度,将抛出StackOverflowError异常,如果虚拟机可以动态扩展,并试图扩展,但内存不足了,或者没有足够内存创建新线程的时候,将抛出OutOfMemoryError异常。

3:堆(Heap)

  堆是可供所有线程共享的区域,类实例和数组分配的区域。启动虚拟机的时候创建,堆中存储的对象受自动内存管理(GC),所以无需手动释放。空间分配也可以是固定大小或动态扩展,内存可不要求连续,这点和栈是一样的。如果需求的堆容量超过了自动内存管理能提供的最大容量,也会抛出OutOfMemoryError异常。

4:方法区(Method Area)

  方法区同样是线程共享的区域,有点类似于传统语言的“Text Segment”区。存储了类结构,例如:运行时常量池,字段和方法数据,以及构造函数和普通方法的字节码内容。还包括一些类,实例,接口初始化时用到的特殊方法。特殊方法例如init等等。

  方法区同样在虚拟机启动的时候创建,尽管方法区是堆的逻辑组成中的一部分,不过这个区可以实现垃圾回收,也可以不实现,规范不做强制要求,代码编译管理策略和物理内存分配都不做要求,具体得看虚拟机的实现了。

  当然,如果申请不到足够的内存,也会抛OutOfMemoryError。

5:运行时常量池(Run-Time Constant Pool)

  顾名思义,是每一个类或接口常量表现形式,包括若干种常量:从编译期可知的值到解析运行才知道的值。每一个常量池都保存在方法区中,在类被加载到虚拟机后创建出来。显然,构造常量池不能超过方法区大小,否则抛OutOfMemoryError。

6:本地方法栈(Native Method Stacks)

  这块区域是为Java调用非Java编写的代码而开辟的空间,实际上就是一块传统语言用到的栈。如果虚拟机不支持native方法,自身也不依赖传统栈,可以不分配本地方法栈空间,如果支持,一般都在线程创建的时候分配空间。本地方法栈的大小调整和前面几个一致。分配的栈容量不得超出本地方法栈最大容量,否则抛StackOverflowError异常,无法申请足够的内存扩展栈的话,将抛出OutOfMemoryError异常。

  官方参考:link

编译Open-JDK-7详细记录

  本次编译的系统环境是Ubuntu Linux 64-bit,编译用户root。需要以下软件包的依赖,如果是新的环境直接复制粘贴到终端即可,如果系统有了也不会重复安装的,建议安装之前把软件仓库update一次。

apt-get install mercurial build-essential gawk m4 openjdk-6-jdk ant 
libasound2-dev libcups2-dev libxrender-dev xutils-dev binutils libmotif3 
libmotif-dev zip libfreetype6-dev xorg-dev x11proto-print-dev

1、下载OpenJDK的源代码

hg clone http://hg.openjdk.java.net/jdk7u/jdk7u-dev
cd jdk7u-dev/
chmod 755 get_source.sh
./get_source.sh

2、设置环境变量

#语言选项
export LANG=C

#bootstrap jdk路径
export ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk-amd64

#允许自动下载依赖
export ALLOW_DOWNLOADS=true

#并行编译的线程数,按CPU核数配置就可以了,我这机器是i7 8核
export HOTSPOT_BUILD_JOBS=8
export ALT_PARALLEL_COMPILE_JOBS=8

#与之前编译的版本做比较,没意义,跳过即可
export SKIP_COMPARE_IMAGES=true

#使用预编译的头文件,不加慢些
export USE_PRECOMPILED_HEADER=true

#要编译的内容,这里只编译了JDK和LANGTOOLS。
export BUILD_LANGTOOLS=true
export BUILD_JDK=true

#不需要打包
export BUILD_DEPLOY=false
export BUILD_INSTALL=false

#设置编译输出的目录
export ALT_OUTPUTDIR=/root/jdk7u-bin

#取消系统java环境变量
unset JAVA_HOME
unset CLASSPATH

  这里要求系统先装一个JDK环境,编译OpenJDK7至少要求OpenJDK6以上,因为编译期间有很多java语言写的过程,这个叫做“Bootstrap JDK”,我这是用apt-get安装的,所以默认路径如此。更多配置信息可以参考源代码目录下的README-builds.html。

3、编译

  用env确认下变量没错的话就可以进行编译了,如果有错误,依据错误提示修正后用make clean清理一次,再执行编译。

make 2>&1 | tee $ALT_OUTPUTDIR/build.log

  这样可以记录下编译的日志,不需要也可以直接make all,我这里编译大概需要15分钟就可以了,看到以下信息表示成功。

#-- Build times ----------
Target all_product_build
Start 2013-12-24 13:04:19
End   2013-12-24 13:21:02
00:01:41 corba
00:04:18 hotspot
00:00:16 jaxp
00:00:19 jaxws
00:09:34 jdk
00:00:32 langtools
00:16:43 TOTAL

4、运行检测

  进入之前配置的输出目录下的bin,执行java -version可以看到build里面加入了用户机器名

root@dorole.com:~/jdk7u-bin/bin# ./java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-stevenyang_2013_12_24_13_04-b00)
OpenJDK 64-Bit Server VM (build 24.60-b04, mixed mode)

  Java的编译和解释就算ok了,接下来还要测试下jvm是否正常。进入jdk7u-bin/hotspot/outputdir目录,可以发现有子目录linux_amd64_compiler2/,前面的linux是根据宿主系统来决定的,我们这里是linux,amd64不用多说,compiler2表示Server VM,compiler1表示Client VM。进入后又有子目录分别对应了不同的优化级别,优化级别越高,性能越牛叉,生成的代码越难以调式,具体哪个目录下有内容得看make的参数,我这里是在product/下面。

  虚拟机的启动器名字叫gamma,先编辑目录下的env.sh,可以看到默认的JAVA_HOME并不是我们自己编译的,修改下即可。可以执行目录下的test_gamma脚本来进行测试,这个脚本主要是调用javac去编译jdk7u-dev/hotspot/make/test/Queens.java,并执行解八皇后问题。

  直接执行gamma可能会失败,因为找不到新编译出来的libjvm.so文件,没关系加入到系统就好了。在/etc/ld.so.conf.d中建立java.conf,内容为libjvm.so所在目录。再执行ldconfig即可。

root@dorole.com:/etc/ld.so.conf.d# cat java.conf
/root/jdk7u-bin/hotspot/outputdir/linux_amd64_compiler2/product

root@dorole.com:/etc/ld.so.conf.d# ldconfig
root@dorole.com:/etc/ld.so.conf.d# ldconfig -p | grep jvm
        libjvm.so (libc6,x86-64) => /root/jdk7u-bin/hotspot/outputdir/linux_amd64_compiler2/product/libjvm.so

  看到有最后一行的输出就可以了,再回到gamma目录,执行就可以了。

root@dorole.com:~/jdk7u-bin/hotspot/outputdir/linux_amd64_compiler2/product# ./gamma -version
Using java runtime at: /root/jdk7u-bin
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-stevenyang_2013_12_24_13_04-b00)
OpenJDK 64-Bit Server VM (build 24.60-b04, mixed mode)

  到此,整个编译OpenJDK就算完成了。

Java NIO 的一些细节

  最近项目中折腾到Java的新I/O接口,不得不说这个NIO的实现思路还是很不错的,相比传统的阻塞式I/O,NIO具有非阻塞,高效率。通过抽象出通道,缓冲器的概念来与数据打交道,减少了很多步骤,使用更为便捷。NIO支持文件I/O和网络I/O,高效性主要是设计结构更接近操作系统惯用模型。ByteBuffer作为最核心的东西,内容也十分的多,本文也主要问绕这个类来写。

  ByteBuffer继承自Buffer,Buffer中有四个比较关键的字段或者叫索引(mark, position, limit, capacity)。四个值有这样的关系:0 <= mark <= position <= limit <= capacity private int mark = -1;
  标记,设置一个标记位,调用mark()可以将mark的值设置为position。

private int position = 0;
  位置,当前数据起始位置,调用put()添加数据,position会自增。随时保持最新数据的最后一个字节位置。调用position()可以得到当前position值,position(int)可以设置position的值。

private int limit;
  界限,不能使用的数据位,即指向一段数据流末尾。调用get()方法返回的数据就是在position和limit之间的数据。调用limit()可以获取limit值,limit(int)设置limit值。

private int capacity;
  容量,即该Buffer的大小,分配空间时候决定的,一直指向最后一个数据地址。

字节缓冲区的几个重要方法:
allocate(int):新建一个Buffer,分配指定size的空间。此时position = 0,limit = capacity,mark = null,所有元素将初始化为0。

allocateDirect(int):这个功能如上,比较牛的是与系统耦合性较高,因此速度更快,但是分配开支也会增大,数据位于常规垃圾回收管理之外。

get()/get(int):get()获取当前position的值,并且对position做自增,表示移动到下个位置。get(int)只取出指定位置的数据,不移动指针。

put(byte)/put(int, byte):put(byte)在position位置存入byte,对position做自增,移动到下个位置。put(int, byte)替换int指定位置的值为byte,不移动指针。

flip():在准备取缓冲区内所有数据的时候必须调用一次,进行这些操作:limit = position,position = 0,mark = -1,意味着之前标记将丢失,从0到limit进行遍历即可得到所有数据,写入也时同样的道理。

mark():对缓冲区的位置做标记,进行这个操作:mark = position。一般会配合reset()来使用,前者将当前位置记住,后者将当前位置设置为记住的位置,这有点像录音机中的A-B复读的意思。对于需要取一段特殊数据是有用的。

reset():重置缓冲区的position为先前mark的位置,进行这个操作:position = mark。如果mark < 0会抛InvalidMarkException异常,也就是没有调用mark()之前,不可以reset。 clear():重置缓冲区指针,进行这些操作:position = 0,limit = capacity,mark = -1。这个操作并不会删除实际的数据,但是指针位置被重置了,和flip()接近。

limit()/limit(int):分别是获取limit和设置limit。需要注意的是设置的时候不能超过capacity,不能小于0,如果position > limit,会将position也设置为limit,相当于缩小了范围。如果mark > limit,则mark = -1,作废。

position()/position(int):分别是获取和设置position,设置的时候不得大于limit,不得小于0,如果mark > position,则mark = -1,作废。

rewind():重绕缓冲区,进行这些操作:position = 0,mark = -1。可见也是类似flip(),可以为存取数据做准备,并且使mark作废。

remaining()/hasRemaining():前者得到剩余数,即position – limit的值。后者是判断position是否小于limit,小于返回true,可以用在取数据时判断是否还有数据。

  等等,还有些就不一一介绍了。

冬日暖阳

  Aperture还是蛮好用的,导入导出,调色,用的及其顺手。居然发现有人把Instagram的滤镜都搬到Aperture中了,太喜爱了~~

  拍摄于东湖公园11月菊花展,主要是找了些逆光的角度拍的。一直比较喜欢佳能的逆光色彩,再加上小痰盂毫无可言的抗光晕,于是就有了下面的图。。

  更多照片可以在我的Flickr看到。

IMG_2983IMG_2985IMG_2989 继续阅读冬日暖阳