java虚拟机

众所周知，jvm的内存是受限的，一为机器的体系架构，二为操作系统本身。
x86,x86-64,sparc,.....的内存映射是不同，而各操作系统的内存管理机制也有区别。
以下是来自http://fengyouhua.javaeye.com/blog/58170 

1. heap设定与垃圾回收java heap分为3个区，young，old和permanent。young保存刚实例化的对象。当该区被填满时，gc会将对象移到old区。permanent区则负责保存反射对象，本文不讨论该区。jvm的heap分配可以使用-x参数设定，

-xms	初始heap大小
-xmx	java heap最大值
-xmn	young generation的heap大小

jvm有2个gc线程。第一个线程负责回收heap的young区。第二个线程在heap不足时，遍历heap，将young 区升级为older区。older区的大小等于-xmx减去-xmn，不能将-xms的值设的过大，因为第二个线程*运行会降低jvm的性能。

为什么一些程序频繁发生gc？有如下原因：

l         程序内调用了system.gc()或runtime.gc()。

l         一些中间件软件调用自己的gc方法，此时需要设置参数禁止这些gc。

l         java的heap太小，一般默认的heap值都很小。

l         频繁实例化对象，release对象。此时尽量保存并重用对象，例如使用stringbuffer()和string()。

         如果你发现每次gc后，heap的剩余空间会是总空间的50%，这表示你的heap处于健康状态。许多server端的java程序每次gc后最好能有65%的剩余空间。经验之谈：

1．server端jvm最好将-xms和-xmx设为相同值。为了优化gc，最好让-xmn值约等于-xmx的1/3[2]。

2．一个gui程序最好是每10到20秒间运行一次gc，每次在半秒之内完成[2]。

注意：

1．增加heap的大小虽然会降低gc的频率，但也增加了每次gc的时间。并且gc运行时，所有的用户线程将暂停，也就是gc期间，java应用程序不做任何工作。

2．heap大小并不决定进程的内存使用量。进程的内存使用量要大于-xmx定义的值，因为java为其他任务分配内存，例如每个线程的stack等。

2．stack的设定

每个线程都有他自己的stack。

-xss	每个线程的stack大小

stack的大小限制着线程的数量。如果stack过大就好导致内存溢漏。-xss参数决定stack大小，例如-xss1024k。如果stack太小，也会导致stack溢漏。

3．硬件环境

硬件环境也影响gc的效率，例如机器的种类，内存，swap空间，和cpu的数量。

如果你的程序需要频繁创建很多transient对象，会导致jvm频繁gc。这种情况你可以增加机器的内存，来减少swap空间的使用[2]。

4．4种gc

第一种为单线程gc，也是默认的gc。，该gc适用于单cpu机器。

第二种为throughput gc，是多线程的gc，适用于多cpu，使用大量线程的程序。第二种gc与第一种gc相似，不同在于gc在收集young区是多线程的，但在old区和第一种一样，仍然采用单线程。-xx:+useparallelgc参数启动该gc。

第三种为concurrent low pause gc，类似于第一种，适用于多cpu，并要求缩短因gc造成程序停滞的时间。这种gc可以在old区的回收同时，运行应用程序。-xx:+useconcmarksweepgc参数启动该gc。

第四种为incremental low pause gc，适用于要求缩短因gc造成程序停滞的时间。这种gc可以在young区回收的同时，回收一部分old区对象。-xincgc参数启动该gc。