Web系统性能调优最佳实践
1 Oracle优化
SGA, 索引，物化视图，SQL语句优化
2 应用服务器优化
2.1 JVM优化
大部分JVM实现允许用户设置JVM Heap大小。开发者可以按照需要调整Heap大小。Heap不宜太大或太小。如果JVM Heap内存太少，则GC要频繁的运行，使得应用经常处于暂停状态。另外，如果JVM Heap分配过多，则GC不会频繁的运行，但是一旦GC运行，它要遍历整个Heap空间，并回收内存，引起长时间的应用停止等待。
理想情况下 GC 周期应该：
1）发生间隔大于 10 秒
2）在 1 至 2 秒内完成
对应WebSphere，我们可以借助wsadmin和Jython脚本确定你的Heap空间是否太大或太小.
2.2 调整连接池
调整合适的连接池大小。一般的应用服务器都允许设置初始池大小、最大池大小、逐增（减）池大小。连接池过大，占用大量持久化提供者资源和RDBMS服务器资源，能够处理的并发请求越多。连接池过小，占用资源少，但能够处理的并发请求少，影响服务性能。
小型（4 个 CPU）数据库服务器的“最佳状态”是提供 100-200 个连接。WebSphere 作为数据库服务器前面的一个连接集线器。连接池的大小限制了开放多少数据库连接来受理传入的页面请求。
2.3 web容器的线程池
线程的数量影响同时并发的请求数量，适度地增加线程池以保证 CPU 能够接受。一般一个 CPU 可以驱动 50 到 75 Java 线程。
打开管理控制台，依次打开目录树，Application servers > server1 > Thread Pools > WebContainer，修改"最大大小"的值，默认是50，改到更大数目，具体视总用户数量和机器的配置而定，一般设置其等于或小于http server设置的MaxKeepAliveRequests的值。
2.4 启用servlet高速缓存
1. Open the administrative console.
2. Click Servers > Application Servers in the console navigation tree.
3. Click a server.
4. Click Web Container.
5. Select Enable servlet caching under the Configuration tab.
6. Click Apply or OK.
7. Restart WebSphere Application Server.
3 代码优化
3.1 Cache中间件
如果一个应用中80% 的时间内都在访问20% 的数据，那么，这时候就应该使用缓存了。在合适的地方加Cache. 假如你的框架是page->filter->action->business->dao->db,我们在filter、 action、business、dao、db之间都可以加Cache。但我们应该在尽量离用户近的地方加Cache。如加到filter前,这样当用户 请求走到filter的时候就结束了。无需在深入action、business、dao，减少服务器压力。
Cache不变化的页面。如页面的公共静态部分Header, Footer.
3.2 页面优化
3.2.1异步加载。
使用Ajax异步请求数据。提高系统相应速度。同时尽可能少的加载数据。在同一个页面中，如果某些数据是在用户触发某事件后才需要显示，我们没有必要一开 始就加载其数据。如在页面同一区域存在多个Div。当用户点击时，才会显示其他Div，我们没有必要一开始就加载所有数据。减少服务器压力。
3.2.2关闭session。
如果Web应用是无状态的，我们应使用<%page session=”false” %>来关闭session。Session管理对系统性能影响极大。
3.2.3 一次Http请求尽量在一个事务里完成，减少与DB的交互。
3.3编写JVM友好代码。
我们在编写Java代码过程中，要及时将不再使用的对象释放。将对象的引用置为null。特别是大对象内存的释放。 如：DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 如果使用完毕应立即将其置为null。如果为null，JVM便知道不再需要它了。GC会回收分配给它的内存。
1.sql 调优
2.程序结构调优
3.数据库参数调优
4.jvm参数调优
5.如果有大量的数据查询，可以进行caching处理。
6.做集群和负载均衡
JVM调优技巧总结
1.升级JVM版本。如果能使用64-bit，使用64-bitJVM。基本上没什么好解释的，很简单将JVM升级到最新的版本。如果你还是使用JDK1.4甚至是更早的JVM，那你首先要做的就是升级。因为JVM从 1.4->1.5->1.6可不是仅仅的版本号升级，或者仅仅往里面加了一堆新的语言特性，这么简单。而是真正在JVM做了重大的改进，每次版本升级，都有巨大的性能升级。尤其是ＳＵＮ认识到ｊａｖａ是知己的全部的时候。如果你经常逛SUN的 JVM论坛，你就会发现实际上JVM上的毛病是这么多。如果你因为各种原因，而不能升级到1.6，那你可以升级到该版本的最新版。
2.选择一个正确的GC（GargageCollection）。
由于当JAVA程序GC的时候，会停下当前程序。尤其FullGC的时候，会停留很长时间。一般对于GUI程序来说，是很难接受的（想想 Eclipse暂停的时候）。JAVA5以后，开始自带了好几种GC，你可以选择一个适合你的种类。有以下四种 SerialCollector，Parallelcollector，ConcurrentCollector，TrainCollector（废弃）。后面几种时候使用并行收集，所以理论上有效率更高（要求你有超过2CUP，但是现在多核开始普及了，呵呵）。提示：更改GC种类以后要适当挺高 JVM的内存量。
3.正确设置内存大小。进行JVM调优时对JVM堆内的各个区域（young,old,perm）正确设置大小。
这个是最困难的调整，因为这个调整会直接影响GC的效率。而且由于各个程序的类型不用，所以没有一个通用的数据。除了几个常用规则以外，需要使用工 具（jstat,jvmstat,jconsole等等）仔细调整。下面会提到几个常用的准则。通常使用一下几个参数调整-Xms-Xmx- XX:MaxPermSize。
3.1调高-XX:NewRatio（NewSize/MaxNewSize）的值，会减少younggc的次数，但会增加oldgc的时间。
3.2增加普通GC的方法（减小FullGC）。扩大young区域的大小（最大40%），并过大Survivor的区域。使得更多的object留在younggen。
4.减小类的使用量，注意类的load和unload，减少JSP页数。
类实际上也是对象，会直接分配perm区域里，即使FullGC也会很少收集。JSP也会分配到perm区域里，效果同理。如果perm过大，超过 XX:MaxPermSize值，会发生OutOfMemoryError:PermGenspace异常。解决方法是提高 -XX:MaxPermSize值。
5.进行JVM调优时避免使用-Xnoclassgc
6.如果是RMI程序，要注意调整RMIDGC的时间。
◆以下是几个写程序时，应该注意的地方。也可减小GC，提高JVM性能。
1.不要使用System.gc()方法。
因为它会产生FullGC。
2.尽可能少分配大的临时对象（生命周期短的）
可能会直接分配到old区域里，old区域只有FullGC的时候会收集。
3.避免使用finalize()方法。
finalize()会增加GC的负担，使用java.lang.ref代替。
JVM调优
关键字: jvm
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？有如下原因：
1）程序内调用了System.gc()或Runtime.gc()。
2）一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
3）Java的Heap太小，一般默认的Heap值都很小。
4）频繁实例化对象，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。
最后附上用java -X 命令查看JVM的配置说明：
D:\j2sdk15\bin>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.
-----------------------------------------------------------------------
JVM配置参数中文说明：
-----------------------------------------------------------------------
1、-Xmixed mixed mode execution (default)
混合模式执行
2、-Xint interpreted mode execution only
解释模式执行
3、-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
设置zip/jar资源或者类（.class文件）存放目录路径
3、-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
追加zip/jar资源或者类（.class文件）存放目录路径
4、-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
预先加载zip/jar资源或者类（.class文件）存放目录路径
5、-Xnoclassgc disable class garbage collection
关闭类垃圾回收功能
6、-Xincgc enable incremental garbage collection
开启类的垃圾回收功能
7、-Xloggc:<file> log GC status to a file with time stamps
记录垃圾回日志到一个文件。
8、-Xbatch disable background compilation
关闭后台编译
9、-Xms<size> set initial Java heap size
设置JVM初始化堆内存大小
10、-Xmx<size> set maximum Java heap size
设置JVM最大的堆内存大小
11、-Xss<size> set java thread stack size
设置JVM栈内存大小
12、-Xprof output cpu profiling data
输入CPU概要表数据
13、-Xfuture enable strictest checks, anticipating future default
执行严格的代码检查，预测可能出现的情况
14、-Xrs reduce use of OS signals by Java/VM (see documentation)
通过JVM还原操作系统信号
15、-Xcheck:jni perform additional checks for JNI functions
对JNI函数执行检查
16、-Xshare:off do not attempt to use shared class data
尽可能不去使用共享类的数据
17、-Xshare:auto use shared class data if possible (default)
尽可能的使用共享类的数据
18、-Xshare:on require using shared class data, otherwise fail.
尽可能的使用共享类的数据，否则运行失败
The -X options are non-standard and subject to change without notice.
调整JVM GC(Garbage Collection)，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，
由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），
所以使用的GC种类也会不同。接下来，我简单介绍一下如何调整GC。
首先说一下如何监视GC，你可以使用我以前文章中提到的JDK中的jstat工具 ，也可以在java程序启动的opt里加上如下几个参数（注:这两个参数只针对SUN的HotSpot VM）：
-XX:-PrintGC Print messages at garbage collection. Manageable.
-XX:-PrintGC Details Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)
当把-XX:-PrintGC Details 加入到java opt里以后可以看见如下输出：
[GC [DefNew: 34538K->2311K(36352K), 0.0232439 secs] 45898K->15874K(520320K), 0.0233874 secs]
[Full GC [Tenured: 13563K->15402K(483968K), 0.2368177 secs] 21163K->15402K(520320K), [Perm : 28671K->28635K(28672K)], 0.2371537 secs]
他们分别显示了GC的过程，清理出了多少空间。第一行GC使用的是 ‘普通GC’(Minor Collections)，第二行使用的是 ‘全GC’(Major Collections)。他们的区别很大，在第一行最后
我们可以看见他的时间是0.0233874秒，而第二行的Full GC的时间是0.2371537秒。第二行的时间是第一行的接近10倍，也就是我们这次调优的重点，减少Full GC 的次数，因为Full GC
会暂停程序比较长的时间，如果Full GC 的次数比较多。程序就会经常性的假死。当然这只是他们的表面现象，接下来我仔细介绍一下GC，和 Full GC（为后面的调优做准备）。
我们知道Java和C++的区别主要是，Java不需要像c++那样，由程序员主动的释放内存。而是由JVM里的GC(Garbage Collection)来，在适当的时候替我们释放内存。GC 的内部工作，
即GC的算法有很多种, 如：标记清除收集器，压缩收集器，分代收集器等等。现在比较常用的是分代收集（也是SUN VM使用的），即将内存分为几个区域，将不同生命周期的对象放在不同区域里
（新的对象会先 生成在Young area，在几次ＧＣ以后，如过没有收集到，就会逐渐升级到Tenured area）。在GC收集的时候，频繁收集生命周期短的区域(Young area)，因为这个区域内的
对象生命周期比较短，GC 效率也会比较高。而比较少的收集生命周期比较长的区域(Old area or Tenured area)，以及基本不收集的永久区(Perm area)。
注：Young area又分为三个区域分别叫Eden，和俩个Survivor spaces。Eden用来存放新的对象，Survivor spaces用于 新对象 升级到 Tenured area时的 拷贝。
我们管收集 生命周期短的区域(Young area) 的收集叫 GC，而管收集 生命周期比较长的区域(Old area or Tenured area)的收集叫 Full GC，因为他们的收集算法不同，
所以使用的时间也会不同。我们要尽量减少 Full GC 的次数。
接下来介绍一下 HotSpot VM GC 的种类，GC在 HotSpot VM 5.0里有四种。一种是默认的叫 serial collector，另外几种分别叫throughput collector，concurrent
low pause collector， incremental (sometimes called train) low pause collector（废弃掉了）。以下是SUN的官方说明：
1. The throughput collector: this collector uses a parallel version of the young generation collector. It is used if the
-XX:+UseParallelGC option is passed on the command line. The tenured generation collector is the same as the serial collector.
2. The concurrent low pause collector: this collector is used if the -Xincgc™ or -XX:+UseConcMarkSweepGC is passed on the command line.
The concurrent collector is used to collect the tenured generation and does most of the collection concurrently with the execution of
the application. The application is paused for short periods during the collection. A parallel version of the young generation copying
collector is used with the concurrent collector. The concurrent low pause collector is used if the option -XX:+UseConcMarkSweepGC is
passed on the command line.
3. The incremental (sometimes called train) low pause collector: this collector is used only if -XX:+UseTrainGC is passed on the
command line. This collector has not changed since the J2SE Platform version 1.4.2 and is currently not under active development.
It will not be supported in future releases. Please see the 1.4.2 GC Tuning Document for information on this collector.
简单来说就是throughput collector和concurrent low pause collector:使用多线程的方式，利用多CUP来提高GC的效率，而throughput collector与concurrent
low pause collector的去别是throughput collector只在young area使用使用多线程，而concurrent low pause collector则在tenured generation也使用多线程。
根据官方文档，他们俩个需要在多CPU的情况下，才能发挥作用。在一个CPU的情况下，会不如默认的serial collector，因为线程管理需要耗费CPU资源。而在两个CPU的情况下，
也挺高不大。只是在更多CPU的情况下，才会有所提高。当然 concurrent low pause collector有一种模式可以在CPU较少的机器上，提供尽可能少的停顿的模式，见下文。
当 要使用throughput collector时，在java opt里加上-XX:+UseParallelGC，启动 throughput collector收集。也可加上-XX:ParallelGCThreads=<desired number>来 改变线程数。
还有两个参数 -XX:MaxGCPauseMillis=<nnn>和 -XX:GCTimeRatio=& lt;nnn>，MaxGCPauseMillis=<nnn>用来控制最大暂停时间，而-XX: GCTimeRatio可以提高 GC说占CPU的比，
以最大话的减小heap。
当要使用 concurrent low pause collector时，在java的opt里加上 -XX:+UseConcMarkSweepGC。concurrent low pause collector还有一种为CPU少的机器
准备的模式，叫Incremental mode。这种模式使用一个CPU来在程序运行的过程中GC，只用很少的时间暂停程序，检查对象存活。
在Incremental mode里，每个收集过程中，会暂停两次，第二次略长。第一次用来，简单从root查询存活对象。第二次用来，详细检查存活对象。整个过程如下：
* stop all application threads; do the initial mark; resume all application threads（第一次暂停，初始话标记）
* do the concurrent mark (uses one procesor for the concurrent work)（运行是标记）
* do the concurrent pre-clean (uses one processor for the concurrent work)（准备清理）
* stop all application threads; do the remark; resume all application threads（第二次暂停，标记，检查）
* do the concurrent sweep (uses one processor for the concurrent work)(运行过程中清理)
* do the concurrent reset (uses one processor for the concurrent work)(复原)
当要使用Incremental mode时，需要使用以下几个变量：
-XX:+CMSIncrementalMode default: disabled 启动i-CMS模式（must with -
XX:+UseConcMarkSweepGC）
-XX:+CMSIncrementalPacing default: disabled 提供自动校正功能
-XX:CMSIncrementalDutyCycle=<N> default: 50 启动CMS的上线
-XX:CMSIncrementalDutyCycleMin=<N> default: 10 启动CMS的下线
-XX:CMSIncrementalSafetyFactor=<N> default: 10 用来计算循环次数
-XX:CMSIncrementalOffset=<N> default: 0 最小循环次数（This is the percentage (0-
100) by which the incremental mode duty cycle is shifted to the right within the period
between minor collections.）
-XX:CMSExpAvgFactor=<N> default: 25 提供一个指导收集数
SUN推荐的使用参数是：
-XX:+UseConcMarkSweepGC \
-XX:+CMSIncrementalMode \
-XX:+CMSIncrementalPacing \
-XX:CMSIncrementalDutyCycleMin=0 \
-XX:CMSIncrementalDutyCycle=10 \
-XX:+PrintGC Details \
-XX:+PrintGCTimeStamps \
-XX:-TraceClassUnloading
注：如果使用throughput collector和concurrent low pause collector，这两种垃圾收集器，需要适当的挺高内存大小，以为多线程做准备。
1 Oracle优化
SGA, 索引，物化视图，SQL语句优化
2 应用服务器优化
2.1 JVM优化
大部分JVM实现允许用户设置JVM Heap大小。开发者可以按照需要调整Heap大小。Heap不宜太大或太小。如果JVM Heap内存太少，则GC要频繁的运行，使得应用经常处于暂停状态。另外，如果JVM Heap分配过多，则GC不会频繁的运行，但是一旦GC运行，它要遍历整个Heap空间，并回收内存，引起长时间的应用停止等待。
理想情况下 GC 周期应该：
1）发生间隔大于 10 秒
2）在 1 至 2 秒内完成
对应WebSphere，我们可以借助wsadmin和Jython脚本确定你的Heap空间是否太大或太小.
2.2 调整连接池
调整合适的连接池大小。一般的应用服务器都允许设置初始池大小、最大池大小、逐增（减）池大小。连接池过大，占用大量持久化提供者资源和RDBMS服务器资源，能够处理的并发请求越多。连接池过小，占用资源少，但能够处理的并发请求少，影响服务性能。
小型（4 个 CPU）数据库服务器的“最佳状态”是提供 100-200 个连接。WebSphere 作为数据库服务器前面的一个连接集线器。连接池的大小限制了开放多少数据库连接来受理传入的页面请求。
2.3 web容器的线程池
线程的数量影响同时并发的请求数量，适度地增加线程池以保证 CPU 能够接受。一般一个 CPU 可以驱动 50 到 75 Java 线程。
打开管理控制台，依次打开目录树，Application servers > server1 > Thread Pools > WebContainer，修改"最大大小"的值，默认是50，改到更大数目，具体视总用户数量和机器的配置而定，一般设置其等于或小于http server设置的MaxKeepAliveRequests的值。
2.4 启用servlet高速缓存
1. Open the administrative console.
2. Click Servers > Application Servers in the console navigation tree.
3. Click a server.
4. Click Web Container.
5. Select Enable servlet caching under the Configuration tab.
6. Click Apply or OK.
7. Restart WebSphere Application Server.
3 代码优化
3.1 Cache中间件
如果一个应用中80% 的时间内都在访问20% 的数据，那么，这时候就应该使用缓存了。在合适的地方加Cache. 假如你的框架是page->filter->action->business->dao->db,我们在filter、 action、business、dao、db之间都可以加Cache。但我们应该在尽量离用户近的地方加Cache。如加到filter前,这样当用户 请求走到filter的时候就结束了。无需在深入action、business、dao，减少服务器压力。
Cache不变化的页面。如页面的公共静态部分Header, Footer.
3.2 页面优化
3.2.1异步加载。
使用Ajax异步请求数据。提高系统相应速度。同时尽可能少的加载数据。在同一个页面中，如果某些数据是在用户触发某事件后才需要显示，我们没有必要一开 始就加载其数据。如在页面同一区域存在多个Div。当用户点击时，才会显示其他Div，我们没有必要一开始就加载所有数据。减少服务器压力。
3.2.2关闭session。
如果Web应用是无状态的，我们应使用<%page session=”false” %>来关闭session。Session管理对系统性能影响极大。
3.2.3 一次Http请求尽量在一个事务里完成，减少与DB的交互。
3.3编写JVM友好代码。
我们在编写Java代码过程中，要及时将不再使用的对象释放。将对象的引用置为null。特别是大对象内存的释放。 如：DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 如果使用完毕应立即将其置为null。如果为null，JVM便知道不再需要它了。GC会回收分配给它的内存。
1.sql 调优
2.程序结构调优
3.数据库参数调优
4.jvm参数调优
5.如果有大量的数据查询，可以进行caching处理。
6.做集群和负载均衡
JVM调优技巧总结
1.升级JVM版本。如果能使用64-bit，使用64-bitJVM。基本上没什么好解释的，很简单将JVM升级到最新的版本。如果你还是使用JDK1.4甚至是更早的JVM，那你首先要做的就是升级。因为JVM从 1.4->1.5->1.6可不是仅仅的版本号升级，或者仅仅往里面加了一堆新的语言特性，这么简单。而是真正在JVM做了重大的改进，每次版本升级，都有巨大的性能升级。尤其是ＳＵＮ认识到ｊａｖａ是知己的全部的时候。如果你经常逛SUN的 JVM论坛，你就会发现实际上JVM上的毛病是这么多。如果你因为各种原因，而不能升级到1.6，那你可以升级到该版本的最新版。
2.选择一个正确的GC（GargageCollection）。
由于当JAVA程序GC的时候，会停下当前程序。尤其FullGC的时候，会停留很长时间。一般对于GUI程序来说，是很难接受的（想想 Eclipse暂停的时候）。JAVA5以后，开始自带了好几种GC，你可以选择一个适合你的种类。有以下四种 SerialCollector，Parallelcollector，ConcurrentCollector，TrainCollector（废弃）。后面几种时候使用并行收集，所以理论上有效率更高（要求你有超过2CUP，但是现在多核开始普及了，呵呵）。提示：更改GC种类以后要适当挺高 JVM的内存量。
3.正确设置内存大小。进行JVM调优时对JVM堆内的各个区域（young,old,perm）正确设置大小。
这个是最困难的调整，因为这个调整会直接影响GC的效率。而且由于各个程序的类型不用，所以没有一个通用的数据。除了几个常用规则以外，需要使用工 具（jstat,jvmstat,jconsole等等）仔细调整。下面会提到几个常用的准则。通常使用一下几个参数调整-Xms-Xmx- XX:MaxPermSize。
3.1调高-XX:NewRatio（NewSize/MaxNewSize）的值，会减少younggc的次数，但会增加oldgc的时间。
3.2增加普通GC的方法（减小FullGC）。扩大young区域的大小（最大40%），并过大Survivor的区域。使得更多的object留在younggen。
4.减小类的使用量，注意类的load和unload，减少JSP页数。
类实际上也是对象，会直接分配perm区域里，即使FullGC也会很少收集。JSP也会分配到perm区域里，效果同理。如果perm过大，超过 XX:MaxPermSize值，会发生OutOfMemoryError:PermGenspace异常。解决方法是提高 -XX:MaxPermSize值。
5.进行JVM调优时避免使用-Xnoclassgc
6.如果是RMI程序，要注意调整RMIDGC的时间。
◆以下是几个写程序时，应该注意的地方。也可减小GC，提高JVM性能。
1.不要使用System.gc()方法。
因为它会产生FullGC。
2.尽可能少分配大的临时对象（生命周期短的）
可能会直接分配到old区域里，old区域只有FullGC的时候会收集。
3.避免使用finalize()方法。
finalize()会增加GC的负担，使用java.lang.ref代替。
JVM调优
关键字: jvm
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？有如下原因：
1）程序内调用了System.gc()或Runtime.gc()。
2）一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
3）Java的Heap太小，一般默认的Heap值都很小。
4）频繁实例化对象，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。
最后附上用java -X 命令查看JVM的配置说明：
D:\j2sdk15\bin>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.
-----------------------------------------------------------------------
JVM配置参数中文说明：
-----------------------------------------------------------------------
1、-Xmixed mixed mode execution (default)
混合模式执行
2、-Xint interpreted mode execution only
解释模式执行
3、-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
设置zip/jar资源或者类（.class文件）存放目录路径
3、-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
追加zip/jar资源或者类（.class文件）存放目录路径
4、-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
预先加载zip/jar资源或者类（.class文件）存放目录路径
5、-Xnoclassgc disable class garbage collection
关闭类垃圾回收功能
6、-Xincgc enable incremental garbage collection
开启类的垃圾回收功能
7、-Xloggc:<file> log GC status to a file with time stamps
记录垃圾回日志到一个文件。
8、-Xbatch disable background compilation
关闭后台编译
9、-Xms<size> set initial Java heap size
设置JVM初始化堆内存大小
10、-Xmx<size> set maximum Java heap size
设置JVM最大的堆内存大小
11、-Xss<size> set java thread stack size
设置JVM栈内存大小
12、-Xprof output cpu profiling data
输入CPU概要表数据
13、-Xfuture enable strictest checks, anticipating future default
执行严格的代码检查，预测可能出现的情况
14、-Xrs reduce use of OS signals by Java/VM (see documentation)
通过JVM还原操作系统信号
15、-Xcheck:jni perform additional checks for JNI functions
对JNI函数执行检查
16、-Xshare:off do not attempt to use shared class data
尽可能不去使用共享类的数据
17、-Xshare:auto use shared class data if possible (default)
尽可能的使用共享类的数据
18、-Xshare:on require using shared class data, otherwise fail.
尽可能的使用共享类的数据，否则运行失败
The -X options are non-standard and subject to change without notice.
调整JVM GC(Garbage Collection)，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，
由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），
所以使用的GC种类也会不同。接下来，我简单介绍一下如何调整GC。
首先说一下如何监视GC，你可以使用我以前文章中提到的JDK中的jstat工具 ，也可以在java程序启动的opt里加上如下几个参数（注:这两个参数只针对SUN的HotSpot VM）：
-XX:-PrintGC Print messages at garbage collection. Manageable.
-XX:-PrintGC Details Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)
当把-XX:-PrintGC Details 加入到java opt里以后可以看见如下输出：
[GC [DefNew: 34538K->2311K(36352K), 0.0232439 secs] 45898K->15874K(520320K), 0.0233874 secs]
[Full GC [Tenured: 13563K->15402K(483968K), 0.2368177 secs] 21163K->15402K(520320K), [Perm : 28671K->28635K(28672K)], 0.2371537 secs]
他们分别显示了GC的过程，清理出了多少空间。第一行GC使用的是 ‘普通GC’(Minor Collections)，第二行使用的是 ‘全GC’(Major Collections)。他们的区别很大，在第一行最后
我们可以看见他的时间是0.0233874秒，而第二行的Full GC的时间是0.2371537秒。第二行的时间是第一行的接近10倍，也就是我们这次调优的重点，减少Full GC 的次数，因为Full GC
会暂停程序比较长的时间，如果Full GC 的次数比较多。程序就会经常性的假死。当然这只是他们的表面现象，接下来我仔细介绍一下GC，和 Full GC（为后面的调优做准备）。
我们知道Java和C++的区别主要是，Java不需要像c++那样，由程序员主动的释放内存。而是由JVM里的GC(Garbage Collection)来，在适当的时候替我们释放内存。GC 的内部工作，
即GC的算法有很多种, 如：标记清除收集器，压缩收集器，分代收集器等等。现在比较常用的是分代收集（也是SUN VM使用的），即将内存分为几个区域，将不同生命周期的对象放在不同区域里
（新的对象会先 生成在Young area，在几次ＧＣ以后，如过没有收集到，就会逐渐升级到Tenured area）。在GC收集的时候，频繁收集生命周期短的区域(Young area)，因为这个区域内的
对象生命周期比较短，GC 效率也会比较高。而比较少的收集生命周期比较长的区域(Old area or Tenured area)，以及基本不收集的永久区(Perm area)。
注：Young area又分为三个区域分别叫Eden，和俩个Survivor spaces。Eden用来存放新的对象，Survivor spaces用于 新对象 升级到 Tenured area时的 拷贝。
我们管收集 生命周期短的区域(Young area) 的收集叫 GC，而管收集 生命周期比较长的区域(Old area or Tenured area)的收集叫 Full GC，因为他们的收集算法不同，
所以使用的时间也会不同。我们要尽量减少 Full GC 的次数。
接下来介绍一下 HotSpot VM GC 的种类，GC在 HotSpot VM 5.0里有四种。一种是默认的叫 serial collector，另外几种分别叫throughput collector，concurrent
low pause collector， incremental (sometimes called train) low pause collector（废弃掉了）。以下是SUN的官方说明：
1. The throughput collector: this collector uses a parallel version of the young generation collector. It is used if the
-XX:+UseParallelGC option is passed on the command line. The tenured generation collector is the same as the serial collector.
2. The concurrent low pause collector: this collector is used if the -Xincgc™ or -XX:+UseConcMarkSweepGC is passed on the command line.
The concurrent collector is used to collect the tenured generation and does most of the collection concurrently with the execution of
the application. The application is paused for short periods during the collection. A parallel version of the young generation copying
collector is used with the concurrent collector. The concurrent low pause collector is used if the option -XX:+UseConcMarkSweepGC is
passed on the command line.
3. The incremental (sometimes called train) low pause collector: this collector is used only if -XX:+UseTrainGC is passed on the
command line. This collector has not changed since the J2SE Platform version 1.4.2 and is currently not under active development.
It will not be supported in future releases. Please see the 1.4.2 GC Tuning Document for information on this collector.
简单来说就是throughput collector和concurrent low pause collector:使用多线程的方式，利用多CUP来提高GC的效率，而throughput collector与concurrent
low pause collector的去别是throughput collector只在young area使用使用多线程，而concurrent low pause collector则在tenured generation也使用多线程。
根据官方文档，他们俩个需要在多CPU的情况下，才能发挥作用。在一个CPU的情况下，会不如默认的serial collector，因为线程管理需要耗费CPU资源。而在两个CPU的情况下，
也挺高不大。只是在更多CPU的情况下，才会有所提高。当然 concurrent low pause collector有一种模式可以在CPU较少的机器上，提供尽可能少的停顿的模式，见下文。
当 要使用throughput collector时，在java opt里加上-XX:+UseParallelGC，启动 throughput collector收集。也可加上-XX:ParallelGCThreads=<desired number>来 改变线程数。
还有两个参数 -XX:MaxGCPauseMillis=<nnn>和 -XX:GCTimeRatio=& lt;nnn>，MaxGCPauseMillis=<nnn>用来控制最大暂停时间，而-XX: GCTimeRatio可以提高 GC说占CPU的比，
以最大话的减小heap。
当要使用 concurrent low pause collector时，在java的opt里加上 -XX:+UseConcMarkSweepGC。concurrent low pause collector还有一种为CPU少的机器
准备的模式，叫Incremental mode。这种模式使用一个CPU来在程序运行的过程中GC，只用很少的时间暂停程序，检查对象存活。
在Incremental mode里，每个收集过程中，会暂停两次，第二次略长。第一次用来，简单从root查询存活对象。第二次用来，详细检查存活对象。整个过程如下：
* stop all application threads; do the initial mark; resume all application threads（第一次暂停，初始话标记）
* do the concurrent mark (uses one procesor for the concurrent work)（运行是标记）
* do the concurrent pre-clean (uses one processor for the concurrent work)（准备清理）
* stop all application threads; do the remark; resume all application threads（第二次暂停，标记，检查）
* do the concurrent sweep (uses one processor for the concurrent work)(运行过程中清理)
* do the concurrent reset (uses one processor for the concurrent work)(复原)
当要使用Incremental mode时，需要使用以下几个变量：
-XX:+CMSIncrementalMode default: disabled 启动i-CMS模式（must with -
XX:+UseConcMarkSweepGC）
-XX:+CMSIncrementalPacing default: disabled 提供自动校正功能
-XX:CMSIncrementalDutyCycle=<N> default: 50 启动CMS的上线
-XX:CMSIncrementalDutyCycleMin=<N> default: 10 启动CMS的下线
-XX:CMSIncrementalSafetyFactor=<N> default: 10 用来计算循环次数
-XX:CMSIncrementalOffset=<N> default: 0 最小循环次数（This is the percentage (0-
100) by which the incremental mode duty cycle is shifted to the right within the period
between minor collections.）
-XX:CMSExpAvgFactor=<N> default: 25 提供一个指导收集数
SUN推荐的使用参数是：
-XX:+UseConcMarkSweepGC \
-XX:+CMSIncrementalMode \
-XX:+CMSIncrementalPacing \
-XX:CMSIncrementalDutyCycleMin=0 \
-XX:CMSIncrementalDutyCycle=10 \
-XX:+PrintGC Details \
-XX:+PrintGCTimeStamps \
-XX:-TraceClassUnloading
注：如果使用throughput collector和concurrent low pause collector，这两种垃圾收集器，需要适当的挺高内存大小，以为多线程做准备。
457
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
