`

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的线程信息

 

工作遇到每小时一次的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中方法

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics