本文分为两个部分：
1，JVM specification s(JVM规范)对JVM内存的描述
2，Sun的JVM的内存机制。
JVM specification对JVM内存的描述
首先我们来了解JVM specification中的JVM整体架构。如下图：
主要包括两个子系统和两个组件：Class loader(类装载器)子系统，Execution engine(执行引擎)子系统；Runtime data area(运行时数据区域)组件，Native interface(本地接口)组件。
Class loader子系统的作用：根据给定的全限定名类名(如
https://www.doczj.com/doc/d79765323.html,ng.Object)来装载class文件的内容到Runtime data area中的method area(方法区域)。Javsa程序员可以extends https://www.doczj.com/doc/d79765323.html,ng.ClassLoader类来写自己的Class loader。
Execution engine子系统的作用：执行classes中的指令。任何JVM specification实现(JDK)的核心是Execution engine，换句话说：Sun的JDK 和IBM的JDK好坏主要取决于他们各自实现的Execution engine的好坏。每个运行中的线程都有一个Execution engine的实例。
Native interface组件：与native libraries交互，是其它编程语言交互的接口。
Runtime data area组件：这个组件就是JVM中的内存。下面对这个部分进行详细介绍。
Runtime data area的整体架构图
Runtime data area主要包括五个部分：Heap(堆),Method Area(方法区域), Java Stack(java的栈),Program Counter(程序计数器),Native method stack(本地方法栈)。Heap和Method Area是被所有线程的共享使用的；而Java stack,Program counter和Native method stack是以线程为粒度的，每个线
程独自拥有。
Heap
Java程序在运行时创建的所有类实或数组都放在同一个堆中。而一个Java虚拟实例中只存在一个堆空间，因此所有线程都将共享这个堆。每一个java程序独占一个JVM实例，因而每个java程序都有它自己的堆空间，它们不会彼此干扰。但是同一java程序的多个线程都共享着同一个堆空间，就得考虑多线程访问对象（堆数据）的同步问题。（这里可能出现的异常https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError: Java heap space）
Method area
在Java虚拟机中，被装载的class的信息存储在Method area的内存中。当虚拟机装载某个类型时，它使用类装载器定位相应的class文件，然后读入这个class文件内容并把它传输到虚拟机中。紧接着虚拟机提取其中的类型信息，并将这些信息存储到方法区。该类型中的类（静态）变量同样也存储在方法区中。与Heap一样，method area是多线程共享的，因此要考虑多线程访问的同步问题。比如，假设同时两个线程都企图访问一个名为Lava的类，而这个类还没有内装载入虚拟机，那么，这时应该只有一个线程去装载它，而另一个线程则只能等待。（这里可能出现的异常https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:PermGen full）
Java stack
Java stack以帧为单位保存线程的运行状态。虚拟机只会直接对Java stack执行两种操作：以帧为单位的压栈或出栈。每当线程调用一个方法的时候，就对当前状态作为一个帧保存到java stack中(压栈)；当一个方法调用返回时，从java stack弹出一个帧(出栈)。栈的大小是有一定的限制，这个可能出现StackOverFlow问题。下面的程序可以说明这个问题。
public class TestStackOverFlow{
public static void main(String[]args){
Recursive r=new Recursive();
r.doit(10000);
//Exception in thread"main"
https://www.doczj.com/doc/d79765323.html,ng.StackOverflowError
}
}
class Recursive{
public int doit(int t){
if(t<=1){
return1;
}
return t+doit(t-1);
}
}
Program counter
每个运行中的Java程序，每一个线程都有它自己的PC寄存器，也是该线程启动时创建的。PC寄存器的内容总是指向下一条将被执行指令的饿“地址
”，这里的“地址”可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量。
Native method stack
对于一个运行中的Java程序而言，它还能会用到一些跟本地方法相关的数据区。当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。本地方法可以通过本地方法接口来访问虚拟机的运行时数据区，不止与此，它还可以做任何它想做的事情。比如，可以调用寄存器，或在操作系统中分配内存等。总之，本地方法具有和JVM相同的能力和权限。(这里出现JVM无法控制的内存溢出问题native heap OutOfMemory)
Sun JVM中对JVM Specification的实现（内存部分）
JVM Specification只是抽象的说明了JVM实例按照子系统、内存区、数据类型以及指令这几个术语来描述的，但是规范并非是要强制规定Java虚拟机实现内部的体系结构，更多的是为了严格地定义这些实现的外部特征。
Sun JVM实现中：Runtime data area(JVM内存)五个部分中的Java Stack, Program Counter,Native method stack三部分和规范中的描述基本一致；但对Heap和Method Area进行了自己独特的实现。这个实现和Sun JVM的Garbage collector（垃圾回收）机制有关，下面的章节进行详细描述。
垃圾分代回收算法（Generational Collecting）
基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。
如上图所示，为Java堆中的各代分布。
1.Young（年轻代）JVM specification中的Heap的一部份
年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。
2.Tenured（年老代）JVM specification中的Heap的一部份
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
3.Perm（持久代）JVM specification中的Method area
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。
浅谈SUN JVM内存管理与应用服务器的优化之SUN JVM内存管理
文章分类:Java编程关键字:j2ee
作者：Jason S.H.Chen
名词解释：
JVM（Java Virtual Machine）：Java虚拟机，所有的Java程序都在Java虚拟机中运行。
元数据：在本文中指用于描述类和接口定义的数据。
在我做J2EE系统开发的工作生涯中，经常遇到技术人员或客户发出诸如此类的感慨：我的J2EE应用系统处理的数据量不大，系统体积也不大，技术架构也没有问题，我的应用服务器的内存有4G或8G；系统运行起来很慢，还经常出现内存溢出错误。真是无奈！每次遇到这样的情况，我心中都会忍不住窃笑之。
其实他们所遇到这种情况，不是技术架构上的问题，不是系统本身的问题，也不是应用服务器的问题，也可能不是服务器的内存资源真的不足的问题。他们花了很多时间在J2EE应用系统本身上找问题（当然一般情况下，这种做法是对的；当出现问题时，在自身上多找找有什么不足），结果还是解决不了问题。他们却忽略了很重要的一点：J2EE应用系统是运行在J2EE应用服务器上的，而J2EE 应用服务器又是运行在JVM（Java Virtual Machine）上的。
其实在生产环境中JVM参数的优化和设置对J2EE应用系统性能有着决定性的作用。本篇我们就来分析JAVA的创建者SUN公司的JVM的内存管理机制（在现实中绝大多数的应用服务器是运行在SUN公司的JVM上的，当然除了SUN公司的JVM，还有IBM的JVM，Bea的JVM等）；下篇咱们具体讲解怎样优化JVM的参数以达到优化J2EE应用的目的。
咱们先来看JVM的内存管理制吧，JVM的早期版本并没有进行分区管理；这样的后果是JVM进行垃圾回收时，不得不扫描JVM所管理的整片内存，所以搜集垃圾是很耗费资源的事情，也是早期JAVA程序的性能低下的主要原因。随着JVM的发展，JVM引进了分区管理的机制。
采用分区管理机制的JVM将JVM所管理的所有内存资源分为2个大的部分。永久存储区（Permanent Space）和堆空间（The Heap Space）。其中堆空间又分为新生区（Young(New)generation space）和养老区（Tenure(Old)generation space），新生区又分为伊甸园（Eden space），幸存者0区（Survivor0space）和幸存者1区（Survivor1space）。具体分区如下图：
那JVM他的这些分区各有什么用途，请看下面的解说。
永久存储区（Permanent Space）：永久存储区是JVM的驻留内存，用于存放JDK 自身所携带的Class,Interface的元数据，应用服务器允许必须的
Class,Interface的元数据和Java程序运行时需要的Class和Interface的元数据。被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM时，释放此区域所控制的内存。
堆空间（The Heap Space）：是JAVA对象生死存亡的地区，JAVA对象的出生，成长，死亡都在这个区域完成。堆空间又分别按JAVA对象的创建和年龄特征分为养老区和新生区。
新生区（Young(New)generation space）：新生区的作用包括JAVA对象的创建和从JAVA对象中筛选出能进入养老区的JAVA对象。
伊甸园（Eden space）：JAVA对空间中的所有对象在此出生，该区的名字因此而得名。也即是说当你的JAVA程序运行时，需要创建新的对象，JVM将在该区为你创建一个指定的对象供程序使用。创建对象的依据即是永久存储区中的元数据。
幸存者0区（Survivor0space）和幸存者1区（Survivor1space）：当伊甸园的控件用完时，程序又需要创建对象；此时JVM的垃圾回收器将对伊甸园区进行垃圾回收，将伊甸园区中的不再被其他对象所引用的对象进行销毁工作。同时将伊甸园中的还有其他对象引用的对象移动到幸存者0区。幸存者0区就是用于
存放伊甸园垃圾回收时所幸存下来的JAVA对象。当将伊甸园中的还有其他对象引用的对象移动到幸存者0区时，如果幸存者0区也没有空间来存放这些对象时，JVM的垃圾回收器将对幸存者0区进行垃圾回收处理，将幸存者0区中不在有其他对象引用的JAVA对象进行销毁，将幸存者0区中还有其他对象引用的对象移动到幸存者1区。幸存者1区的作用就是用于存放幸存者0区垃圾回收处理所幸存下来的JAVA对象。
养老区（Tenure(Old)generation space）：用于保存从新生区筛选出来的JAVA 对象。
上面我们看了JVM的内存分区管理，现在我们来看JVM的垃圾回收工作是怎样运作的。首先当启动J2EE应用服务器时，JVM随之启动，并将JDK的类和接口，应用服务器运行时需要的类和接口以及J2EE应用的类和接口定义文件也及编译后的Class文件或JAR包中的Class文件装载到JVM的永久存储区。在伊甸园中创建JVM，应用服务器运行时必须的JAVA对象，创建J2EE应用启动时必须创建的JAVA对象；J2EE应用启动完毕，可对外提供服务。
JVM在伊甸园区根据用户的每次请求创建相应的JAVA对象，当伊甸园的空间不足以用来创建新JAVA对象的时候，JVM的垃圾回收器执行对伊甸园区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到幸存者0区。
如果幸存者0区有足够控件存放则直接放到幸存者0区；如果幸存者0区没有足够空间存放，则JVM的垃圾回收器执行对幸存者0区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到幸存者1区。
如果幸存者1区有足够控件存放则直接放到幸存者1区；如果幸存者0区没有足够空间存放，则JVM的垃圾回收器执行对幸存者0区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并将那些被其他对象所引用的JAVA对象移动到养老区。
如果养老区有足够控件存放则直接放到养老区；如果养老区没有足够空间存放，则JVM的垃圾回收器执行对养老区区的垃圾回收工作，销毁那些不再被其他对象引用的JAVA对象（如果该对象仅仅被一个没有其他对象引用的对象引用的话，此对象也被归为没有存在的必要，依此类推），并保留那些被其他对象所引用的JAVA对象。如果到最后养老区，幸存者1区，幸存者0区和伊甸园区都没有空间的话，则JVM会报告“JVM堆空间溢出（https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:Java heap space）”，也即是在堆空间没有空间来创建对象。
这就是JVM的内存分区管理，相比不分区来说；一般情况下，垃圾回收的速度要快很多；因为在没有必要的时候不用扫描整片内存而节省了大量时间。
通常大家还会遇到另外一种内存溢出错误“永久存储区溢出
（https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:Java Permanent Space）”。
好，本篇对SUN的JVM内存管理机制讲解就到此为止，下一篇我们将详细讲解怎样优化SUN的JVM让我们的J2EE系统运行更快，不出现内存溢出等问题。
浅谈SUN JVM内存管理与应用服务器的优化之服务器内存分配与优化
文章分类:Java编程
作者：Jason S.H.Chen
上篇(https://www.doczj.com/doc/d79765323.html,/blog/526356)给大家介绍了SUN JVM的内存管理机制。本篇主要讲解与性能相关的JVM参数，怎样使用工具监控JVM的内存分配使用情况和怎样调整JVM参数让系统在特定硬件配置下达到最优化的性能。
通过上篇SUN JVM内存管理机制的介绍，大家都知道了SUN JVM内存分为永久存储区，伊甸园，幸存者0区，幸存者1区和养老区等几个区域。他们的作用以及垃圾回收处理过程在上篇也做了详细介绍。下面我们就来看看和这些内存分区相关的JVM参数。
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对内存资源的使用，不会充分的利用所有的内存资源。
到此我们就不难理解上文提到的“我的服务器有8g内存，系统也就100M左右，居然出现内存溢出”这个“怪现象”了。在上文我曾提到“永久存储区溢出（https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:Java Permanent Space）”和“JVM堆空间溢出（https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:Java heap space）”这两种溢出错误。现在大家都知道答案了：“永久存储区溢出（https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:Java Permanent Space）”乃是永久存储区设置太小，不能满足系统需要的大小，此时只需要调整-XX:PermSize和-XX:MaxPermSize这两个参数即可。“JVM堆空间溢出（https://www.doczj.com/doc/d79765323.html,ng.OutOfMemoryError:Java heap space）”错误是JVM堆空间不足，此时只需要调整-Xms和-Xmx这两个参数即可。
到此我们知道了，当系统出现内存溢出时，是哪些参数设置不合理需要调整。但我们怎么知道服务器启动时，到底JVM内存相关参数的值是多少呢。在实践中，经常遇到对JVM参数进行设置了，并且自己心里觉得应该不会出现内存溢出了；但不幸的是内存溢出还是发生了。很多人百思不得其解，那我可以肯定地告诉你，你设置的JVM参数并没有起作用（本文咱不探讨没有起作用的原因）。不信我们就去看看，下面介绍如何使用SUN公司的内存使用监控工具jvmstat.
本文只介绍如何使用jvmstat查看内存使用，不介绍其安装配置。有兴趣的读者，可到SUN公司的官方网站下载一个，他本身已经带有非常详细的安装配置文档了。这里假设你已经在你的应用服务器上配置好了jvmstat了。那我们就开始使用他来看看我们的服务器到底是有没有按照我们设置的参数启动。
首先启动服务器，等服务器启动完。开启DOS窗口（此例子是在windows下完成，linux下同样），在dos窗口中输入jps这个命令。如下图
窗口中会显示所有JAVA应用进程列表，列表的第一列为应用的进程ID,第二列为应用的名字。在列表中找到你的应用服务器的进程ID,比如我这里的应用服务器进程ID为1856.在命令行输入visualgc1856回车。进入jvmstat的主界面，如下图：
上图分别标注了伊甸园，幸存者0区，幸存者1区，养老区和永久存储区。图上直观的反应出各存储区的大小，已经使用的大小，剩下的空间大小，并用数字标出了各区的大小；如果你这上面的数字和你设置的JVM参数相同的话，那么恭喜你，你设置的参数已经起作用，如果和你设置的不一致的话，那么你设置的参数没有起作用（可能是服务器的启动方式没有载入你的JVM参数设置。）
在优化服务器的时候，这个工具很有用，他占用资源少。可以随应用服务器一直保持开启状态，如果系统发生内粗溢出，可以一眼就看出是那个区发生了溢出。根据观察结果进行进一步优化。
Java虚拟机（JVM）参数配置说明 在Java、J2EE大型应用中，JVM非标准参数的配置直接关系到整个系统的性能。 JVM非标准参数指的是JVM底层的一些配置参数，这些参数在一般开发中默认即可，不需要任何配置。但是在生产环境中，为了提高性能，往往需要调整这些参数，以求系统达到最佳新能。另外这些参数的配置也是影响系统稳定性的一个重要因素，相信大多数Java开发人员都见过“O utOfMem ory”类型的错误。呵呵，这其中很可能就是JVM参数配置不当或者就没有配置没意识到配置引起的。 为了说明这些参数，还需要说说JDK中的命令行工具一些知识做铺垫。 首先看如何获取这些命令配置信息说明： 假设你是windows平台，你安装了J2SDK，那么现在你从cmd控制台窗口进入J2SDK安装目录下的bin目录，然后运行java命令，出现如下结果，这些就是包括java.exe工具的和J VM的所有命令都在里面。 ----------------------------------------------------------------------- D:\j2sdk15\bin>java Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is client.
Java 中的堆和栈 简单的说： Java把内存划分成两种：一种是栈内存，一种是堆内存。 在函数中定义的一些基本类型的变量和对象的引用变量都在函数的栈内存中分配。 当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。 堆内存用来存放由new创建的对象和数组。 在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。 在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。 引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。 具体的说： 栈与堆都是Java用来在Ram中存放数据的地方。与C++不同，Java自动管理栈和堆，程序员不能直接地设置栈或堆。 Java的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立，它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的，堆的优势是可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的，Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是，由于要在运行时动态分配内存，存取速度较慢。 栈的优势是，存取速度比堆要快，仅次于寄存器，栈数据可以共享。但缺点是，存在栈中的数据大小与生存期必须是确定的，缺乏灵活性。栈中主要存放一些基本类型的变量（,int, short, long, byte, float, double, boolean, char）和对象句柄。 栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义： int a = 3; int b = 3； 编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。这时，如果再令a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响到b 的值。要注意这种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。 String是一个特殊的包装类数据。可以用： String str = new String("abc"); String str = "abc"; 两种的形式来创建，第一种是用new()来新建对象的，它会在存放于堆中。每调用一次就会创建一个新的对象。 而第二种是先在栈中创建一个对String类的对象引用变量str，然后查找栈中有没有存放"abc"，如果没有，则将"abc"存放进栈，并令str指向”abc”，如果已经有”abc”则直接令 str指向“abc”。 比较类里面的数值是否相等时，用equals()方法；当测试两个包装类的引用是否指向同一个对象时，用==，下面用例子说明上面的理论。 String str1 = "abc"; String str2 = "abc"; System.out.println(str1==str2); //true
Eclipse中JVM内存设置 eclipse.ini内存设置 -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M 这里有几个问题： 1. 各个参数的含义什么？ 2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？ 3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？ 下面我们一一进行回答 1. 各个参数的含义什么？ 参数中-vmargs的意思是设置JVM参数，所以后面的其实都是JVM的参数了，我们首先了解一下JVM内存管理的机制，然后再解释每个参数代表的含义。 堆(Heap)和非堆(Non-heap)内存 按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memo ry)”。可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。 堆内存分配
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-X mx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。 非堆内存分配 JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxP ermSize设置最大非堆内存的大小，默认是物理内存的1/4。 JVM内存限制(最大值) 首先JVM内存限制于实际的最大物理内存(废话！呵呵)，假设物理内存无限大的话，J VM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows 系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。 2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？ 通过上面对JVM内存管理的介绍我们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操作系统。所以说设置VM参数导致程序无法启动主要有以下几种原因： 1) 参数中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize； 2) -Xmx的值和-XX:MaxPermSize的总和超过了JVM内存的最大限制，比如当前操作系统最大内存限制，或者实际的物理内存等等。说到实际物理内存这里需要说明一点的是，如果你的内存是1024MB，但实际系统中用到的并不可能是1024MB，因为有一部分被硬件占用了。 3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？
JVM内存大小配置方式 By:sheagle@https://www.doczj.com/doc/d79765323.html, 1.最简单的方式，tomcat当中进行配置 用记事本打开tomcat安装路径下bin文件夹中的Catalina.bat，在文件当中添加set JAV A_OPTS=-Xms256m-Xmx512m 该方式只适合于使用Catalina Start指令及其类似方式通过执行Startup.bat中的指令方式启动tomcat 2.在Eclipse当中配置tomcat的内存启动大小 Eclipse->Window->Preferences->Server->Runtime Environments->选中Apache Tomcat v5.0->点击Edit按钮->在弹出对话框里点击JRE后面的Installed JREs按钮->在弹出对话框中选中tomcat使用的那个JRE->点击Edit按钮->在弹出对话框中，找到Default VM Arguments，并在输入框中输入：-Xms256M-Xmx512M 该修改方式只适合于使用Eclipse启动tomcat 3.在注册表中修改tomcat大小 如果你的电脑上边安装了tomcat服务，那么你也可以通过以下设置来修改通过
服务启动时的tomcat内存。 打开tomcat安装路径下bin文件夹中的tomcat6w.exe。选中Java,修改Inital memory pool和Maximum memory pool 该修改方式只适合于使用“服务”方式启动tomcat 总结： 关于tomcat启动时JVM虚拟机内存大小的配置，针对每种情况会有多种不同的配置方式，基本上都是修改配 置文件中参数的大小，无论使用哪种配置方式进行配置，只要能达到效果即可
基础知识-Java JVM参数设置及日志查看 JVM内存参数 -Xms：初始堆大小；默认值为物理内存的1/64(<1GB)，默认(MinHeapFreeRatio 参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制。-Xmx：最大堆大小；默认值为物理内存的1/4(<1GB) 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制 -Xmn：年轻代大小(1.4or lator)；注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。整个堆大小=年轻代大小+ 年老代大小+ 持久代大小。增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8 -XX:NewSize：设置年轻代大小(for 1.3/1.4) -XX:MaxNewSize：年轻代最大值(for 1.3/1.4) -XX:PermSize：设置持久代(perm gen)初始值物理内存的1/64 -XX:MaxPermSize：设置持久代最大值；默认值为物理内存的1/4。注意IBM的JDK设置此参数无效。 -Xss：每个线程的堆栈大小；JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K.更具应用的线程所需内存大小进行调整.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。一般小的应用，如果栈不是很深，应该是128k够用的大的应用建议使用256k。这个选项对性能影响比较大，需要严格的选择。 -XX:ThreadStackSize：Thread Stack Size；(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]，此值设置和-Xss设置相似，目前较多使用-Xss。 -XX:NewRatio：年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)-XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5 当Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。 -XX:SurvivorRatio：Eden区与Survivor区的大小比值；设置为8,则两个Survivor 区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10 -XX:LargePageSizeInBytes：内存页的大小不可设置过大，会影响Perm的大小，默认为128m -XX:+UseFastAccessorMethods：原始类型的快速优化 -XX:+DisableExplicitGC：关闭System.gc()；这个参数谨慎使用。 -XX:MaxTenuringThreshold：垃圾最大年龄；如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率.如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率，该参数只有在串行GC时才有效。 -XX:+AggressiveOpts：加快编译 -XX:+UseBiasedLocking：锁机制的性能改善
JVM内存最大能调多大分析【经典】 2010-11-10 13:21 转载自 最终编辑 上次用weblogic 把 -XmxXXXX 设成2G，就启动不起来，设小点就起来了，当时很气，怎么2G都起不了，今天在看到了一篇解释，转过来了 这次一位老友提出了这个问题，记得当年一个java高手在blogjava提出后，被骂得半死。大家使用java -XmxXXXX -version版本得出了不同的结论。后来老友说大概是1800M左右，我当时反驳，“我设置过服务器8G内存，我使用两个tomcat，每个2G”。为此，我翻开所有的JVM的内存管理的c代码，没有任何结论。我不是linux内核程序员，但是我看过linux的源码，知道32位体系结构的计算机寻址空间是2^32=4G，intel Pentium Pro处理器寻址空间是36位，CPU内部增加了PAE寄存器。用于处理多出来的4根地址 线的使用，所以PAE的技术实现最大2^36=64G寻址。通过linux的内核源码，标准Linux内核对于物理内存的管理采用1:3的分配比例，即物理内存的1/4为内核空间（kernel space），剩下的3/4为用户进程空间（user space），因此，在一台4G内存的服务器上，用户进程可使用的内存最大也就是3G。当进程被内核调入CPU运行时，不同的地址空间数据会被调入4G以内的用户进程空间，其实就能用3G。 IA32架构上，单一进程是不能使用超过4G的内存空间的。但是我记得我给mysql server分配内存大约是左右,不是2的32次方-1，我分配java 2G内存的计算机是IBM的RS6000. 经过不同平台的测试,我得出了大概的数值,win2k下左右,nt下,原因是这样的,Classic VM and HotSpot VM 存放用户区的连续地址中,NT把 kernel DLLs 放在 0x7c 开头的地址空间,所以nt下只有<2G的空间,所以JVM heap 使用极限是2G.用户的dll开始于0x,用户的应用程序开始于0x00400000.我现在唯一确定的是sun可能为了防止和某些 JVM插件的冲突,把dll的地址给rebase一下,这样使用的空间就很少了一部分.为什末rebase,原因是这样的,因为在windows下编译 dll 的默认地址都是, 一般在release之前的时候要rebase一下,rebase 的-b 这个参数是指定一个起始地址,MSDN建议地址是0x，这个工具随visual studio和platform SDK发放。 例如 -b 0x6D000000 \jdk\jre\bin\*.dll \jdk\jre\bin\hotspot\这样你的JVM用的内存多一些,目前关于这个我只能得到BEA的 JRockit最大也只能使用内存,看来各家编译JDK时都作了些手脚. 目前只能得到bea的的-Xmx最小值是16 MB,sun的资料很不全,还好java开源了,可以不依靠sun了. sun提供的资料 Maximum Address Space Per Process Operating System Maximum Address Space Per Process
首先需要注意的是在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存，这个数值不能准确的反应堆内存的真实占用情况，因为GC过后这个值是不会变化的，因此内存调优的时候要更多地使用JDK提供的内存查看工具，比如JConsole和Java VisualVM。 对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数，过多的GC和Full GC是会占用很多的系统资源（主要是CPU），影响系统的吞吐量。特别要关注Full GC，因为它会对整个堆进行整理，导致Full GC一般由于以下几种情况： 旧生代空间不足 调优时尽量让对象在新生代GC时被回收、让对象在新生代多存活一段时间和不要创建过大的对象及数组避免直接在旧生代创建对象 Pemanet Generation空间不足 增大Perm Gen空间，避免太多静态对象 统计得到的GC后晋升到旧生代的平均大小大于旧生代剩余空间 控制好新生代和旧生代的比例 System.gc()被显示调用 垃圾回收不要手动触发，尽量依靠JVM自身的机制 调优手段主要是通过控制堆内存的各个部分的比例和GC策略来实现，下面来看看各部分比例不良设置会导致什么后果 1）新生代设置过小 一是新生代GC次数非常频繁，增大系统消耗；二是导致大对象直接进入旧生代，占据了旧生代剩余空间，诱发Full GC
2）新生代设置过大 一是新生代设置过大会导致旧生代过小（堆总量一定），从而诱发Full GC；二是新生代GC耗时大幅度增加 一般说来新生代占整个堆1/3比较合适 3）Survivor设置过小 导致对象从eden直接到达旧生代，降低了在新生代的存活时间 4）Survivor设置过大 导致eden过小，增加了GC频率 另外，通过-XX:MaxTenuringThreshold=n来控制新生代存活时间，尽量让对象在新生代被回收 由内存管理和垃圾回收可知新生代和旧生代都有多种GC策略和组合搭配，选择这些策略对于我们这些开发人员是个难题，JVM提供两种较为简单的GC策略的设置方式 1）吞吐量优先 JVM以吞吐量为指标，自行选择相应的GC策略及控制新生代与旧生代的大小比例，来达到吞吐量指标。这个值可由-XX:GCTimeRatio=n来设置 2）暂停时间优先 JVM以暂停时间为指标，自行选择相应的GC策略及控制新生代与旧生代的大小比例，尽量保证每次GC造成的应用停止时间都在指定的数值范围内完成。这个值可由-XX:MaxGCPauseRatio=n来设置
几招轻松搞定JVM内存设置 2010-09-17 14:04 gk23 javaeye 我要评论(0)字号：T | T 你知道如何进行JVM内存设置吗，这里向大家描述一下，设置JVM内存的参数有四个：分别是-Xss 每个线程的Stack大小；-Xmx Java Heap最大值；-Xms Java Heap初始值和-Xmn Java Heap Young区大小。 AD：本文向大家简单介绍一下进行JVM内存设置几种方法，安装Java开发软件时，默认安装包含两个文件夹，一个JDK(Java开发工具箱)，一个JRE(Java运行环境，内含JVM)，其中JDK内另含一个JRE。如果只是运行Java程序，则JRE已足够；而JDK则只有开发人员才用到。这里将为大家介绍设置JVM内存分配的几招。 浅谈JVM内存设置的几个妙招 一、设置JVM内存设置 1. 设置JVM内存的参数有四个： -Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定； -Xms Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值； -Xmn Java Heap Young区大小，不熟悉最好保留默认值； -Xss 每个线程的Stack大小，不熟悉最好保留默认值； 2. 如何分配JVM内存设置： （1）当在命令提示符下启动并使用JVM时（只对当前运行的类Test生效）： 1.java -Xmx128m -Xms64m -Xmn32m -Xss16m Test 2. （2）当在集成开发环境下（如eclipse）启动并使用JVM时： a. 在eclipse根目录下打开eclipse.ini，默认内容为（这里设置的是运行当前开发工具的JVM内存分配）：
本文分为两个部分： 1，JVM specification s(JVM规范) 对JVM内存的描述 2，Sun的JVM的内存机制。 JVM specification对JVM内存的描述 首先我们来了解JVM specification中的JVM整体架构。如下图： 主要包括两个子系统和两个组件： Class loader(类装载器) 子系统，Execution engine(执行引擎) 子系统；Runtime data area (运行时数据区域)组件， Native interface(本地接口)组件。 Class loader子系统的作用：根据给定的全限定名类名(如 https://www.doczj.com/doc/d79765323.html,ng.Object)来装载class文件的内容到 Runtime data area中的method area(方法区域)。Javsa程序员可以extends https://www.doczj.com/doc/d79765323.html,ng.ClassLoader类来写自己的Class loader。 Execution engine子系统的作用：执行classes中的指令。任何JVM specification实现(JDK)的核心是Execution engine，换句话说：Sun 的JDK 和IBM的JDK好坏主要取决于他们各自实现的Execution engine的好坏。每个运行中的线程都有一个Execution engine的实例。 Native interface组件：与native libraries交互，是其它编程语言交互的接口。 Runtime data area 组件：这个组件就是JVM中的内存。下面对这个部分进行详细介绍。
Runtime data area的整体架构图 Runtime data area 主要包括五个部分：Heap (堆), Method Area(方法区域), Java Stack(java的栈), Program Counter(程序计数器), Native method stack(本地方法栈)。Heap 和Method Area是被所有线程的共享使用的；而Java stack, Program counter 和Native method stack是以线程为粒度的，每个线
JAVA开发我们常常会遇到内存分配和性能调优方面的要求，在新能调优方面没有固定的最优方案，这就需要我们去根据实际情况分析，然后给出最适合的方案。因此利用JConsole可以很方便进行观察。 一、被控端配置 要运行JConsole，需要首先被监控端要进行相应的配置，我们要在被控制端启动JAVA 程序时补充上如下代码： -Dcom.sun.management.jmxremote //这里指定启动JMX -Dcom.sun.management.jmxremote.port=8061 //这里是指定端口号 -Dcom.sun.management.jmxremote.ssl=false //这里指定是否使用SSL进行通讯加密 -Dcom.sun.management.jmxremote.authenticate=false //这里指定是否使用证书 如果我们需要启用远程用户身份认证（用户名和密码），则可以加入下面的参数： -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=$JRE_HOME/lib/management/p assword.properties //这里指定你放置的password.properties 文件的路径-Dcom.sun.management.jmxremote.access.file=$JRE_HOME/lib/management/acce ss.properties 这里指定你放置的access.properties文件的路径 这里的password.properties 和access.properties文件可以从 JRE_HOME/lib/management/目录下去复制jmxremote.password.template文件到指定目录下，并将其改名为password.properties 。在这个文件中可以指定用户名和口令，此文件可以用记事本打开。指定格式是“user password”，前面是用户名，然后跟空格，然后是此用户密码，如果有多个用户，则换行输入按此格式输入第二个用户信息，以此类推。 从JRE_HOME/lib/management/目录下去复制jmxremote.access文件到指定目录下，在这个文件中可以指定用户名的权限，此文件可以用记事本打开。指定格式是“user权限”，前面是用户名，然后跟空格，然后是此用户权限，如果有多个用户，则换行输入按此格式输入第二个用户信息，以此类推。 配置好被监控端后，就可以-Dcom.sun.management.jmxremote.authenticate设置为false，则以上配置不生效。 配置好被监控端后，我们可以像正常情况一样启动应用程序，这时我们就可以在远端通过JConsole监视此应用程序的运行情况了。 二、使用JConsole
JVM性能调优-JVM内存区域划分 1.程序计数器（线程私有） 程序计数器（Program Counter Register），也有称作为PC寄存器。保存的是程序当前执行的指令的地址（也可以说保存下一条指令的所在存储单元的地址），当CPU需要执行指令时，需要从程序计数器中得到当前需要执行的指令所在存储单元的地址，然后根据得到的地址获取到指令，在得到指令之后，程序计数器便自动加1或者根据转移指针得到下一条指令的地址，如此循环，直至执行完所有的指令。也就是说是用来指示执行哪条指令的。 由于在JVM中，多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，因此，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则就会影响到程序的正常执行次序。因此，可以这么说，程序计数器是每个线程所私有的。 在JVM规范中规定，如果线程执行的是非native方法，则程序计数器中保存的是当前需要执行的指令的地址；如果线程执行的是native方法，则程序计数器中的值是undefined。 由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变，因此，对于程序计数器是不会发生内存溢出现象(OutOfMemory)的。 异常情况： 不存在 2.Java栈（线程私有）
Java栈也称作虚拟机栈（Java Vitual Machine Stack） Java栈中存放的是一个个的栈帧，每个栈帧对应一个被调用的方法，在栈帧中包括局部变量表、操作数栈、指向当前方法所属的类的运行时常量池的引用、方法返回地址、额外的附加信息。当线程执行一个方法时，就会随之创建一个对应的栈帧，并将建立的栈帧压栈。当方法执行完毕之后，便会将栈帧出栈。因此可知，线程当前执行的方法所对应的栈帧必定位于Java栈的顶部。 局部变量表，用来存储方法中的局部变量（包括在方法中声明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小了，因此在程序执行期间局部变量表的大小是不会改变的。 存储内容：引用对象，returnAddress类型。Long和double类型占用2个局部变量空间，其余的数据类型占据一个。局部变量表空间在编译期间完成分配。
JVM优化配置 OOM这个缩写就是Java程序开发过程中让人最头痛的问题：Out of Memory在很多开发人员的开发过程中，或多或少的都会遇到这类问题，这类问题定位比较困难，往往需要 根据经验来判断可能出现问题的代码。原因主要是 两个：对象没有被释放（多种情况引起，往往是比较隐蔽的引用导致被Hold而无法被回 收）。另一种就是真的 Memory不够用了，需要增加 JVM的 Heap来满足应用程序的需求。最近有同事发的关于解决OOM勺问题，让我了解了原来 OOM 除了在JVM Heap不够时会发生，在 Native Heap不够的时候也会发生，同时JVM Heap和Native Heap存在着相互影响和平衡的关系，因此就仔细的去看了关于 OOM和JVM配置优化的内 容。 OOM 其他语言类似于 C,Delphi等等由于内存都是由自己分配和管理，因此内存泄露的问题比 较常见，同时也是很头痛的一件事情。而Java的对象生命周期管 理都是JVM来做的，简化了开发人员的非业务逻辑的处理，但是这种自动管理回收机制也是基于一些规则的，而违背了这些规则的时候，就会造成所谓的 “Memory Leak'。 OOM(Java Hea p) 错误提示：https://www.doczj.com/doc/d79765323.html, ng.OutOfMemoryError 。 这类OOMi由于JVM分配的给应用的 Heap Memory已经被耗尽，可能是因为应用在高负荷的情况下的却需要很大的内存，因此可以通过修改JVM参数来增加 Java Heap Memory （不过也不能无限制增加，后面那种OOMt可能就是因为这个原因而产生）。另 一种情况是因为应用程序使用对象或者资源没有释放，导致内存消耗 持续增加，最后出现 OOM这类问题引起的原因往往是应用已不需要的对象还被其他有效对象所引用，那么就无法释放，可能是业务代码逻辑造成的（异常处理不够例如10等资源），也可能是对于第三方开源项目中资源释放了解不够导致使用以后资源没有释放（例如 JDBC的Resultset等）。 几个容易出现问题的场景: 1.应用的缓存或者Collection :如果应用要缓存 Java对象或者是在一个 Collection 中保存对象，那么就要确定是否会有大量的对象存入，要做保护，以防止在 大数据量下大量内存被消耗，同时要保证Cache的大小不会无限制增加。 2.生命周期较长的对象：尽量简短对象的生命周期，现在采用对象的创建 释放代价已经很低，同时作了很好的优化，要比创建一个对象长期反复使用要好。如果
Websphere7.0环境下修改JVM的内存设置 方法1：修改配置的方式 通过修改server.xml进行JVM堆大小的设置： servel.xml文件路径：/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/22Node01Cell/nodes/Node01/server s/server1 server.xml中修改或增加配置 -----------------------------------------------------------------------------------------------------------
JVM的结构 从功能上分，Java虚拟机主要由六个部分组成，可以分成三类： 第一类：JVM API：就是我们最常用的Java API，它是开发人员和Java交互的入口，它主要是JAVA_HOME/jre/lib下的运行时类库rt.jar和编译相关的tools.jar 第二类：JVM内部组件 类装载器(ClassLoader)：将Byte Array的.class文件装载、链接和初始化。 内存管理(Memory Managent)：为对象分配内存，以及释放内存。后者就是垃圾回收Garbage Collector（GC）。由于JVM最复杂的、最影响性能的就是GC，所以内存管理一般就指垃圾回收。 诊断接口(Diagostics Interface)：这主要体现在JVMTI(jdk1.4下的JVMPI和JVMDI)，它主要用来诊断程序的问题和性能，一般提供给工具厂商实现。如eclispe IDE下的debug功能，Jprofiler 性能调优工具。 类解释器(Interpreter)：解释装载进虚拟机的class对象，包括JIT等特性相关。 第三类：平台相关接口(Platform Interface)：主要为了跨操作系统平台重用JVM代码，不过，它和我们开发人员关系不大。 在以上六个组件中，我们开发人员最关心的是ClassLoader和GC，用Java做系统框架、容器和它们密切相关。做业务系统时一些基础代码也和它们打交道，譬如最常用的Class.forName(),Thread.currentThread.getContextClassLoader()。我们仔细想想，为什么是上面两个问题？因为，它和我们class的整个生命周期最为相关：怎么将一个class和相关class 加载进来，class实例什么时候创建，什么时候被销毁？ 所以，下面的部分我们要专门讨论这些问题。 在JVM中有两种垃圾方式，一种叫做Minor（次收集），另一种叫做Major（主收集）。其中Minor在Young Generation的空间被对象全部占用后执行，主要是对Young Generation中的对象进行垃圾收集。而Major是针对于整个Heap size的垃圾收集。其中Minor方式的收集经常发生，并且Minor收集所占用的系统时间小。Major方式的垃圾收集则是一种“昂贵”的垃圾收集方式，因为在Major要对整个Heap size进行垃圾收集,这会使得应用停顿的时间变得较长。 java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar 使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。 java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx 256m SwingSet2.jar 采用-XX:+UseConcMarkSweepGC选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适
1, 设置Eclipse 内存使用情况 修改eclipse 根目录下的eclipse.ini 文件 -vmargs // 虚拟机设置,说明后面是VM 的参数 -Xms40m //Xms 是默认的虚拟机内存大小 -Xmx256m //Xmx 是最大内存 -XX:PermSize=128M // 非堆内存设置,最小堆大小。一般报内存不足时,都是说这个太小,堆空间剩余小于5%就会警告,建议把这个稍微设 //大一点,不过要视自己机器内存大小来设置 -XX:MaxPermSize=256M 注意：为何将上面的参数写入到eclipse.ini 文件Eclipse 没有执行对应的设置？ 这是因为我们没有遵守eclipse.ini 文件的设置规则： 参数形如“项值”这种形式，中间有空格的需要换行书写；如果值中有空格的需要用双引号包括起来。比如我们使用-vm C:/Java/jre1.6.0/bin/javaw.exe 参数设置虚拟机，在eclipse.ini 文件中要写成这样： 1. -vm 2. C:/Java/jre1.6.0/bin/javaw.exe 按照上面所说的，最后参数在eclipse.ini 中可以写成这个样子：
1.-vmargs 2. -Xms128M 3. -Xmx512M 4. -XX:PermSize=64M 5. -XX:MaxPermSize=128M 实际运行的结果可以通过Eclipse 中“Help-”“About Eclipse SDK 窗”口里面的“Configuration Details 按钮”进行查看。另外需要说明的是，Eclipse 压缩包中自带的eclipse.ini 文件内容是这样的： 1.-showsplash https://www.doczj.com/doc/d79765323.html,.eclipse.platform 3. --launcher.XXMaxPermSize 4.256m 5.-vmargs 6. -Xms40m 7. -Xmx256m 其中-auncher.XXMaxPermSize （注意最前面是两个连接线）跟-XX:MaxPermSize参数的含义基本是一样的，我觉得唯一的区别就是前者是 动的时候设置的参数，而后者是eclipse所使用的JVM中的参数。其实二者设置一个就可以了，所以这里可以把-auncher.XXMaxPermSize eclipse.exe 启和下一行使用#
JVM环境变量配置手册
目录 1.概述 (1) 1.1.JVM (1) 1.2.配置说明 (1) 2.JVM参数设置 (1) 2.1.内存组成 (1) 2.2.内存分配 (2) 2.2.1.堆内存分配 (2) 2.2.2.非堆内存分配 (3) 2.3.内存限制 (3) 3.JVM的GC (3) 3.1.GC策略 (4) 3.1.1.堆内存GC (4) 3.1.2.非堆内存不GC (4) 3.2.GC种类 (4) 3.2.1.单线程收集器（Serial Collector） (4) 3.2.2.并行收集器（Parallel Collector） (5) 3.2.3.并发收集器（Concurrent Collector） (5) 4.JVM参数设置 (5) 4.1.部分相关参数 (6) 4.1.1.内存相关参数 (6) 4.1.2.收集器相关参数 (7) 4.2.GC性能 (8) 4.2.1.堆（Total Heap） (8) 4.2.2.年轻代（Young Generation） (8) 4.3.总结 (9) 5.常用配置方式 (11) 5.1.Eclipse (11) 5.2.Tomcat (12)
1.概述 1.1.JVM JVM（Java Virtual Machine），亦称Java虚拟机，是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。引入Java虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java 语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。Java虚拟机在执行字节码时，把字节码解释成具体平台上的机器指令执行。 这就是Java的能够“一次编译，到处运行”的原因。 1.2.配置说明 一个Java程序的运行是需要通过JVM的编译的，所以JVM的配置可以直接影响Java程序的运行效果的，所以在运行一个Java程序之前我们需要对JVM 做相应的配置。 接下来，我们会对一些基本的参数以及对不同平台下的不同程序下的JVM 配置做一些介绍。 2.JVM参数设置 2.1.内存组成 Java 虚拟机具有一个堆(Heap)，堆是运行时的数据区域，所有类实例和数组的内存均从此处分配。堆是在Java 虚拟机启动时创建的。在JVM中堆之外的内存称为非堆内存(Non-heap memory)。 可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java 代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存