深入Java虚拟机

一 深入Java虚拟机：JVM中的Stack和Heap

在JVM中，静态属性保存在Stack指令内存区，动态属性保存在Heap数据内存区。本文将从JVM的角度来讲解Java虚拟机的这一机制。

在JVM中，内存分为两个部分，Stack（栈）和Heap（堆），这里，我们从JVM的内存管理原理的角度来认识Stack和Heap，并通过这些原理认清Java中静态方法和静态属性的问题。

一般，JVM的内存分为两部分：Stack和Heap。

Stack（栈）是JVM的内存指令区。Stack管理很简单，push一定长度字节的数据或者指令，Stack指针压栈相应的字节位移；pop一定字节长度数据或者指令，Stack指针弹栈。Stack的速度很快，管理很简单，并且每次操作的数据或者指令字节长度是已知的。所以Java 基本数据类型，Java 指令代码，常量都保存在Stack中。

Heap（堆）是JVM的内存数据区。Heap 的管理很复杂，每次分配不定长的内存空间，专门用来保存对象的实例。在Heap 中分配一定的内存来保存对象实例，实际上也只是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法（方法是指令，保存在Stack中）,在Heap 中分配一定的内存保存对象实例和对象的序列化比较类似。而对象实例在Heap 中分配好以后，需要在Stack中保存一个4字节的Heap 内存地址，用来定位该对象实例在Heap 中的位置，便于找到该对象实例。

由于Stack的内存管理是顺序分配的，而且定长，不存在内存回收问题；而Heap 则是随机分配内存，不定长度，存在内存分配和回收的问题；因此在JVM中另有一个GC进程，定期扫描Heap ，它根据Stack中保存的4字节对象地址扫描Heap ，定位Heap 中这些对象，进行一些优化（例如合并空闲内存块什么的），并且假设Heap 中没有扫描到的区域都是空闲的，统统refresh（实际上是把Stack中丢失了对象地址的无用对象清除了），这就是垃圾收集的过程；关于垃圾收集的更深入讲解请参考51CTO之前的文章《JVM内存模型及垃圾收集策略解析》。

JVM的体系结构

我们首先要搞清楚的是什么是数据以及什么是指令。然后要搞清楚对象的方法和对象的属性分别保存在哪里。

1）方法本身是指令的操作码部分，保存在Stack中；

2）方法内部变量作为指令的操作数部分，跟在指令的操作码之后，保存在Stack中（实际上是简单类型保存在Stack中，对象类型在Stack中保存地址，在Heap 中保存值）；上述的指令操作码和指令操作数构成了完整的Java 指令。

3）对象实例包括其属性值作为数据，保存在数据区Heap 中。

非静态的对象属性作为对象实例的一部分保存在Heap 中，而对象实例必须通过Stack中保存的地址指针才能访问到。因此能否访问到对象实例以及它的非静态属性值完全取决于能否获得对象实例在Stack中的地址指针。

非静态方法和静态方法的区别：

非静态方法有一个和静态方法很重大的不同：非静态方法有一个隐含的传入参数，该参数是JVM给它的，和我们怎么写代码无关，这个隐含的参数就是对象实例在Stack中的地址指针。因此非静态方法（在Stack中的指令代码）总是可以找到自己的专用数据（在Heap 中的对象属性值）。当然非静态方法也必须获得该隐含参数，因此非静态方法在调用前，必须先new一个对象实例，获得Stack中的地址指针，否则JVM将无法将隐含参数传给非静态方法。

静态方法无此隐含参数，因此也不需要new对象，只要class文件被ClassLoader load进入JVM的Stack，该静态方法即可被调用。当然此时静态方法是存取不到Heap 中的对象属性的。

总结一下该过程：当一个class文件被ClassLoader load进入JVM后，方法指令保存在Stack中，此时Heap 区没有数据。然后程序技术器开始执行指令，如果是静态方法，直接依次执

行指令代码，当然此时指令代码是不能访问Heap 数据区的；如果是非静态方法，由于隐含参数没有值，会报错。因此在非静态方法执行前，要先new对象，在Heap 中分配数据，并把Stack中的地址指针交给非静态方法，这样程序技术器依次执行指令，而指令代码此时能够访问到Heap 数据区了。

静态属性和动态属性：

前面提到对象实例以及动态属性都是保存在Heap 中的，而Heap 必须通过Stack中的地址指针才能够被指令（类的方法）访问到。因此可以推断出：静态属性是保存在Stack中的，而不同于动态属性保存在Heap 中。正因为都是在Stack中，而Stack中指令和数据都是定长的，因此很容易算出偏移量，也因此不管什么指令（类的方法），都可以访问到类的静态属性。也正因为静态属性被保存在Stack中，所以具有了全局属性。

在JVM中，静态属性保存在Stack指令内存区，动态属性保存在Heap数据内存区。

原文地址：http://developer.51cto.com/art/201003/188753.htm

二 关于Java中内存溢出的解决办法

J2EE应用系统是运行在J2EE应用服务器上的，而j2ee应用服务器又是运行在JVM上的，生成环境中JVM参数的优化和设置对于J2EE应用系统性能有着决定性的作用。要优化系统，则需要对JVM参数进行合理的设置，所以我们需要了解究竟在什么地方进行设置、有哪些参数以及各参数的意义分别是什么，并且我们还得了解JVM的内存管理机制究竟是个什么玩意儿？其实我们在网上搜索引擎上，一搜就有可以获取到一大把相关信息，关键是我们如何深入的理解它们。那么下面我们就简单的介绍一下究竟什么是JVM的内存管理机制吧~！

JVM的早期版本并没有进行分区管理；这样的后果是JVM进行垃圾回收时，不得不扫描JVM所管理的整片内存，所以搜集垃圾是很耗费资源的事情，也是早起JAVA程序的性能低下的主要原因。随着JVM的发展，JVM引进了分区管理的机制。

JVM所管理的所有内存资源分为2个大的部分。永久存储区（Permanent Space） 和堆空间（The Heap Space）。其中对堆空间又分为新生区（）和养老区，新生区又分为伊甸园，幸存者0区、幸存1区。如下图：

关于个分区的用途，大家可以参考其他相关文档。本教程所要处理的问题是如何解决内存溢出的问题。接下来以tomcat服务器为例：

我们首先得找到内存管理所要设置的参数在哪个文件：＜CATALINA_HOME＞/bin/catalina.bat。

需要添加一行代码：

JAVA_OPTS=\"-Xms512m-Xmx512m -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=256m\"

下面分别对各参数进行介绍和解释：

JVM 相关参数：

参数名参数说明

-server 启用能够执行优化的编译器, 显著提高服务器的性能，但使用能够执行优化的编译器时，服务器的预备时间将会较长。生产环境的服务器强烈推荐设置此参数。

-Xss 单个线程堆栈大小值；JDK5.0 以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。

-XX:+UseParNewGC 可用来设置年轻代为并发收集【多CPU】，如果你的服务器有多个CPU，你可以开启此参数；开启此参数，多个CPU 可并发进行垃圾回收，可提高垃圾回收的速度。此参数和+UseParallelGC，-XX:ParallelGCThreads搭配使用。

+UseParallelGC 选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。可提高系统的吞吐量。

-XX:ParallelGCThreads 年轻代并行垃圾收集的前提下（对并发也有效果）的线程数，增加并行度，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。永久存储区相关参数：参数名参数说明

-Xnoclassgc 每次永久存储区满了后一般GC 算法在做扩展分配内存前都会触发一次FULL GC，除非设置了-Xnoclassgc.

-XX:PermSize 应用服务器启动时，永久存储区的初始内存大

-XX:MaxPermSize 应用运行中，永久存储区的极限值。为了不消耗扩大JVM 永久存储区分配的开销，将此参数和-XX:PermSize这个两个值设为相等。堆空间相关参数参数名参数说明

-Xms 启动应用时，JVM 堆空间的初始大小值。

-Xmx 应用运行中，JVM 堆空间的极限值。为了不消耗扩大JVM 堆控件分配的开销，将此参数和-Xms 这个两个值设为相等，考虑到需要开线程，讲此值设置为总内存的80%.

-Xmn 此参数硬性规定堆空间的新生代空间大小，推荐设为堆空间大小的1/4。

上面所列的JVM 参数关系到系统的性能，而其中-XX:PermSize，

-XX:MaxPermSize，-Xms，-Xmx 和-Xmn 这5 个参数更是直接关系到系统的性能，系统是否会出现内存溢出。

-XX:PermSize 和-XX:MaxPermSize 分别设置应用服务器启动时，永久存储区的初始大小和极限大小；在生成环境中强烈推荐将这个两个值设置为相同的值，以避免分配永久存储区的开销，具体的值可取系统“疲劳测试”获取到的永久存储区的极限值；如果不进行设置-XX:MaxPermSize 默认值为64M,一般来说系统的类定义文件大小都会超过这个默认值。

-Xms 和-Xmx 分别是服务器启动时，堆空间的初始大小和极限值。-Xms的默认值是物理内存的1/64 但小于1G，-Xmx 的默认值是物理内存的1/4 但小于1G.在生产环境中这些默认值是肯定不能满足我们的需要的。也就是你的服务器有8g 的内存，不对JVM 参数进行设置优化，应用服务器启动时还是按默认值来分配和约束JVM 对内存资源的使用，不会充分的利用所有的内存资源。

结论：“永久存储区溢出（java.lang.OutOfMemoryError:Java Permanent Space）”乃是永久存储区设置太小，不能满足系统需要的大小，此时只需要调整-XX:PermSize 和-XX:MaxPermSize 这两个参数即可。“JVM 堆空间溢出（java.lang.OutOfMemoryError: Java heap space）”错误是JVM 堆空间不足，此时只需要调整-Xms 和-Xmx 这两个参数即可。

到此我们知道了，当系统出现内存溢出时，是哪些参数设置不合理需要调整。但我们怎么知道服务器启动时，到底JVM 内存相关参数的值是多少呢？

这个问题其实Sun公司早已经意料到了，所以给我们开发了内存使用监控工具jvmstat.

大家可以到ORACLE官网进行下载。用它可以很方便的看到我们的服务器内存使用情况。

将下载的jvmstat包解压到如“C:\\ProgramFiles\\Java\\jvmstat”（这是我本地java路径，大家可以根据自己所安装的java环境的路径进行解压）。启动完之后我们就可以使用visualgc命令了，cmd进入命令符窗口，输入tasklist（windows下查看进程任务PID）查找到你要检测进程PID.然后直接输入visualgc PID 就会弹出三个可见视图。

原文链接：http://blog.csdn.net/czp0608/article/details/7352024