Java JVM设置对性能的影响
启动的时候设置JVM的可用内存，因为默认的大小才16M（好像是吧）
可以用java -Xmx256m 设成256M
更改 Java 堆大小
Java™ 堆大小确定应该为 JVM 进程保留多少内存。缺省情况下
堆大小（-Xms 和 -Xmx 设置）设置为 512 MB。该设置对于大多数 Webform Server 部署而言，应该已
足够。
You can get the absolute upper limit with a simple experiment on the platform:
% java -Xmx<limit> -version
If you get an error, that limit is already too much. Find the largest number you can
provide and still get a version, and that's your upper limit.
Then you have to account for non-heap memory for threads, memory-mapped buffers, etc.
JVM的堆, 不制定的话, 最小2m, 最大64m. 一般情况下不需要改变. 但是特殊情况, 不变
大是不行的.
JVM的堆还分 New和OLD两个领域, New领域里, gc是高速的(0.01 ~ 0.1秒). 经过32
次gc, 残留下来的入OLD领域, OLD领域里是 full gc, 速度很慢(0.1 ~ 1秒). New领
域还分为Eden领域和Survivor领域, Object刚生成的时候, 进Eden. 两者的比例关系推荐为3:1.
至于什么时候是特殊情况, 那就不好判断了. hehe, 当时我的一个项目处理出现严重问题,
根本就想不到这方面. 3个月后才解决.
D:\myworkjava>java -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
The -X options are non-standard and subject to change without notice.
首先第三种爱清，每执行一次java ...或javaw ...就会启动一个JVM。
对于应用程序，要看指的是什么应用程序，如Web应用程序、企业应用程序、执行java ...启动的应
用程序（也许可称作Console Application）。Console Application当然就是每个生活服务程序一
个JVM中，Web应用程序和企业应用程序可以多个应用程序运行于一个JVM上，企业应用程序可以运行于多
个JVM中。
这个值受操作系统给每个进程的最大内存寻址空间限制。
windows下我试的结果：最大1024M
weblogic JRockit JVM 最大可以1.8G
现在windows下每个进程分配的空间为4G
java jvm heap size.....eclipse java.lang.OutOfMemoryError: Java Heap Space错误
一直都知道可以设置jvm heap大小，一直用eclipse写/调试java程序。一直用命令行or console加参数跑程序。现象：在eclipse的配置文件eclipse.ini中设置-vmargs -Xms500m -Xmx1024m，在eclipse中直接run 或者debug某些耗内存的程序时依然出现java.lang.OutOfMemoryError: Java Heap Space错误，即通常认为的内存不足，java虚拟机内存不够用。而在命令行加这些参数则有效果，不会出错。这说明一个问题，这些参数根本没有起作用。
今天需要在eclipse里调试程序，还没到需要调试的地方就heap error了，在网上搜了很多地方，得到了最终的答案：
选中被运行的类第三种情续，点击菜单‘run->run...’，选择(x)=Argument标签页下的vm arguments框里输入 -Xmx800m, 保存运行。
原来还需要对每个project单独设置，汗...
zz
有三种可能导致OutOfMemoryError。首先是，此JVM有真实的内存泄漏，导致此JVM堆在内部实现时产生了一个Bug。这极不可靠。所有JVM都经过充分的测试，并且，如果有人发现这种bug，它将绝对是最高的优先级。因此你可以非常宽心地排除这种可能性。
第二种可能的OutOfMemoryError原因只不过是，你没有为你的应用程序运行时给予足够多的可用内存。这种情况，有两种可能的方案，或者增加 JVM堆可用大小，或者减少你的应用程序所需的内存总量。提高JVM可用堆大小可以简单的使用JVM的 -Xmx 参数。假如你将此参数设置尽可能的大（可用内存极限不要超过系统物理内存，否则你的应用程序将分页并暂停），仍然有以上所提到的内存问题，那么，你需要减 少你的应用程序所可能用到内存总量。减少应用程序内存可能是简单的，你可能允许一些集合过大，例如使用了许多大的缓冲区。或者它过于复杂，要求你重新实现 一些类，乃至重新设计应用程序。
读者 Jams Stauffer 指出有些JVM（例如 sun的 JVMs），还有一个“Perm”参数用来处理JVM结构与类对象。如果你正在使用一个数量非常巨大的类集，它有可能运行在"Perm"空间之外，然后你 需要增加此空间的大小，例如，sun的JVM使用 -XX:PermSize 与 -XX:MaxPermSize 选项。
第三种导致OutOfMemoryError最为常见，无心的对象引用保持。你没有明确无误的释放对象，以致于你的堆增长再增长，直到你没有额外的空间。
处理OutOfMemoryError:
是JVM内部的BUG？不太可能。如果是小说 第三种感情，这是优先级最高的BUG（为什么还没有人发现它，而你碰到了？）。
没有足够的内存分配给实际运行的应用程序？两种选择：使用-Xmx参数增加堆的最大使用内存（或者使用-XX:MaxPermSize参数增加Perm空 间大小）; 或者使用更小的集合/缓冲区/表空间/对象.....，以减少所需要的内存总量，也就是说，可以调整对象大小，重新设计与重新实现你的应用程 序。
无心的对象引用保持？找到保持这些无意引用的源对象，改变它并释放这些对象。在IBM开发者社区的文章纲要式的揭示了这样一个通用的处理过程。这个过程主 要是等到应用程序到达恒定状态－－你将期望最多的新创建的对象是临时对象，并且可以被垃圾收集器收集。这常常是在应用程序所有的初始化工作完成之后。
强迫垃圾收集，获得一个堆的对象快照。
做任何工作可能正在导到无意的对象引用保持。
强迫另一次垃圾收集并获得第二次堆的对象快照。
比较这两个快照，观察从第一个快照到第二个快照哪些对象在数量上有所增加。因为你在快照之前强迫垃圾收集，剩下的将是所有被应用程序引用的对象，比较两个快照将准确的标识那些新创建的、保留在应用程序里的对象。
根据你对应用程序的认识，决定两个快照比较中，哪些对象正在无意的保持对象引用。
跟踪前导引用，找到哪些对象正在引用这些无意的保持对象，直到你找到导致此问题的源对象
启动虚拟机的时候，加上一个参数：-Xms800m -Xmx800m就好了
-Xms <size>
设置JVM初始化堆内存大小
-Xmx <size>
设置JVM最大的堆内存大小
如果是应用程序，则：java -Xms800m -Xmx800m 你的类名
如果是tomcat之类的web服务器
 |  |  |  |
另外设置环境变量
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "
一台后端server第三种生存，OS为Slackware 8.1，装了tomcat 4.1.30，近期在繁忙时期经常会死机，死状就是"java.lang.OutOfMemoryError： unable to create new native thread".是tomcat创建不了新的线程来应答请求了。于是我搭了一个环境专门来测试这个问题。内存为2G，CPU为四颗2.8G，tomcat 4.1.30，写一个最简单的JSP页面，如下：
代码 <%
try
{
Thread.sleep（30000）；
out.println（"fuck"）；
} catch （InterruptedException e） {
e.printStackTrace（）；
} %>
然后开Jmetor来压，同时开jconsole来监测tomcat的情况，并不断调整XMX，XMS，XSS这三个参数，得出下表：
XMX XMS XSS down时的tomcat thread数
500M 500M 128K 642
800M 800M 64K 485
1024M 1024M 64K 374
1024M 1024M 128K 374
1024M 1024M 512K 371
根据该表，可以看出，随XMX，即是分配给JVM的内存数越大，tomcat所能开的thread数就越小，而Xss这个参数几乎不影响任何测试结果。我猜想tomcat开线程是使用linux的内存，而不是JVM的内存。当分配给JVM的内存越大，操作系统所能用于分配的内存就越小，于是所能开的线程数就越小。
大家有什么解决方案吗?难道大家都没遇过这个问题?我的设想是可能linux初始每个进程(也就是tomcat开的线程)有一个初始大小，这应该是一个内核参数来的，应该把它调小就可以了，但我不知道怎样去调。
>>>QQ470681378