Java 调优参数大全

JAVA_OPTS

JAVA_OPTS="-server -Xms2048m -Xmx2048m -Xss512k"

-server:一定要作为第一个参数，在多个CPU时性能佳，在Linux上缺省采用server模式，而windows上默认是client模式
-Xms：初始Heap大小，使用的最小内存,cpu性能高时此值应设的大一些
-Xmx：java heap最大值，使用的最大内存
上面两个值是分配JVM的最小和最大内存，取决于硬件物理内存的大小，建议均设为物理内存的一半。
-XX:PermSize:设定内存的永久保存区域
-XX:MaxPermSize:设定最大内存的永久保存区域
-XX:MaxNewSize:
-Xss 15120 这使得JBoss每增加一个线程（thread)就会立即消耗15M内存，而最佳值应该是128K,默认值好像是512k.
+XX:AggressiveHeap 会使得 Xms没有意义。这个参数让jvm忽略Xmx参数,疯狂地吃完一个G物理内存,再吃尽一个G的swap。
-Xss：每个线程的Stack大小
-verbose:gc 现实垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
-Xmn：young generation的heap大小，一般设置为Xmx的3、4分之一
-XX:+UseParNewGC ：缩短minor收集的时间
-XX:+UseConcMarkSweepGC ：缩短major收集的时间
提示：此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。

 

• tomcat7内存溢出错误的一些原因和解决方案

tomcat内存出错的一些原因:
1、建立的过多的对象，导致堆区内存不足
2、有代码被对象持有而导致垃圾收集器无法清理
3、超过了系统文件的大小限制，这样你需要提高你的权限或者用一个不受限制的。
4、你工程的线程数目过多，某些系统在同一个进程里对线程数目有限制，去看系统文档，和学习怎么提高这个数目
5、系统也许限制了你的进程的内存大小
6、JVM有bug，一般在低版本的jvm才出现
还介绍了内存溢出的一些常见处理方式
1、如果发现一个servlet装载大量的内容进入内存，你应该检查下你的代码是不是有bug
2、手动增加堆内存，导致没有空间去创建必须创建的那些线程所需要的栈空间，每个系统对线程创建所要消耗的栈默认不太相同，但是基本都高于2M，而且这个不能通过设置-Xss去减少
所以有一个规则，在32位系统下，对堆内存的分配一般不超过1024M
3、深度递归算法会导致内存出问题，因为方法信息都在栈中，所以一个可以用-Xss增加栈空间，另一个最好去优化你的算法
4、加载了大量的jar包或者同时维持几个项目将消耗你的非堆内存，在这种情况下-XX:MaxPermSize 去增加你的非堆内存
5、强引用导致垃圾收集器无法回收内存。可能会出现jsp重编译，工程重新加载，这将消耗大量时间，只到非堆内存得到清理或者内存溢出。

 

• OutOfMemoryError:unable to create new native thread

来自：http://hi.baidu.com/hexiong/item/037488116cefd90a8ebde4b1

在java应用中，有时候会出现这样的错误：OutOfMemoryError: unable to create new native thread.这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。
那么是什么原因造成这种问题呢？

每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。

这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。

给出一个有关能够创建线程的最大个数的估算公式：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
对于jdk1.5而言，假设操作系统保留120M内存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads

 

• 检测当前JVM内存使用情况

System.out.println("JVM MAX MEMORY: " + Runtime.getRuntime().maxMemory()/1024/1024+"M"); 

System.out.println("JVM IS USING MEMORY:" + Runtime.getRuntime().totalMemory()/1024/1024+"M"); 

System.out.println("JVM IS FREE MEMORY:" + Runtime.getRuntime().freeMemory()/1024/1024+"M");

这三个方法都是说JVM的内存使用情况而不是操作系统的内存：

    maxMemory()这个方法返回的是java虚拟机（这个进程）能构从操作系统那里挖到的最大的内存，以字节为单位，如果在运行java程序的时候，没有添加-Xmx参数，那么就是64兆，也就是说maxMemory()返回的大约是64*1024*1024字节，这是java虚拟机默认情况下能从操作系统那里挖到的最大的内存。如果添加了-Xmx参数，将以这个参数后面的值为准，例如java -cp ClassPath -Xmx512m ClassName，那么最大内存就是512*1024*0124字节。

    totalMemory()这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小，也就是java虚拟机这个进程当时所占用的所有内存。如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，直挖到maxMemory()为止，所以totalMemory()是慢慢增大的。如果用了-Xms参数，程序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数，然后在这些内存用的差不多的时候，再去挖。

    freeMemory()是什么呢，刚才讲到如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，但是java虚拟机100％的情况下是会稍微多挖一点的，这些挖过来而又没有用上的内存，实际上就是freeMemory()，所以freeMemory()的值一般情况下都是很小的，但是如果你在运行java程序的时候使用了-Xms，这个时候因为程序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数，这个时候，挖过来的内存可能大部分没用上，所以这个时候freeMemory()可能会有些

 

• Linux下的一些常用调优命令

检测当前JVM内存使用情况： 使用kill -QUIT pid的方式查看jvm的线程信息

 

• Tomcat6+的JreMemoryLeakPreventionListener1小时执行一次full GC

工作遇到每小时一次的full gc问题，并且一次运行8秒，影响体验。故转来一篇日志，Mark一下
项目部署在Tomcat7上，操作系统是centOS5.5，打印出gc的日志，发现有些full gc在heap还很空余的时候执行，后来仔细一看，发现一小时执行一次，日志如下：
2011-12-13T19:01:36.706+0800: 1.111: [Full GC (System) [PSYoungGen: 1936K->0K(597312K)] [PSOldGen: 0K->1860K(1365376K)] 1936K->1860K(1962688K) [PSPermGen: 10426K->10426K(21248K)], 0.0461030 secs] [Times: user=0.06 sys=0.00, real=0.04 secs]

2011-12-13T20:01:36.816+0800: 3601.221: [Full GC (System) [PSYoungGen: 33170K->0K(597312K)] [PSOldGen: 1860K->30610K(1365376K)] 35030K->30610K(1962688K) [PSPermGen: 52266K->52266K(52352K)], 0.3710140 secs] [Times: user=0.37 sys=0.01, real=0.37 secs]

2011-12-13T21:01:37.201+0800: 7201.606: [Full GC (System) [PSYoungGen: 3424K->0K(597312K)] [PSOldGen: 30610K->33665K(1365376K)] 34034K->33665K(1962688K) [PSPermGen: 52400K->52400K(83968K)], 0.3356130 secs] [Times: user=0.34 sys=0.00, real=0.33 secs]

然后google，发现是Tomcat的JreMemoryLeakPreventionListener调用的full gc，目的是为了方式内存泄露，其中的代码如下：

synchronized(GC.lock){l = GC.latencyTarget;if(l != 9223372036854775807L)break label0;GC.daemon = null;}return;}long l1 = GC.maxObjectInspectionAge();if(l1 >= l){System.gc();l1 = 0L;}
可以
看到调用了System.gc()，有以下几种办法可以停止这个一小时一次的full gc：

1.通过添加jvm参数
-XX:+DisableExplicitGC
  来制止显式调用的full gc，这里需要说一点：有些帖子说
-XX:-DisableExplicitGC是停止full gc，
-XX:+DisableExplicitGC是启动full gc，纯属扯淡。

2.给
JreMemoryLeakPreventionListener添加一个参数，如下

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"gcDaemonProtection="false"/>

这样的话还是会有守护进程，只是不执行full gc了。

3.把这个listener从tomcat的server.xml里去掉。

我采用的是第2中方法