标签：
1.JDK版本
尽可能的使用高版本的JDK版本，这通常可以带来免费的性能提升。当前前提是版本是稳定的，并且相应的应用服务器或者开源第三方工具等，也可以基于此版本稳定运行。
2.字节码验证
如果编译的代码，以及依赖的第三方jar包都是可信赖的话，可以关闭字节码验证，从而节省类加载时间，可通过-XVerify:none关闭字节码验证。
3.JIT编译方式
HotSpot有2种JIT编译方式，分别是Client模式和Server模式，Client模式的特点是启动快、占用内存少、JIT编译器生成代码的速度也更快，Server模式则会会生成更优的机器码，所以Server模式要收集更多的应用程序行为。通常如果作为服务器会选择-server模式，这样会在长时间运行中获益。
4.GC调优
4.1原则
1）尽量避免Full GC。Full GC的时间消耗是最长的，所以GC优化的首要原则是避免Full GC。
2）GC内存最大化原则。Java堆空间越大，垃圾收集器的效果越好，应用程序运行也越流畅。
3）GC调优3选2原则。在吞吐量、延迟、内存占用三者中，某个属性的性能提升总会牺牲另外一个或者两个，所以不可能达到3者最优，而应该选择应用程序最关注的2点进行调优。
这里有个比较容易搞混的概念，吞吐量是单位时间内处理的工作量，例如每秒处理了1000个事务，延迟是指应用程序从开始工作到工作完成消耗的时间，例如请求花了10s处理完成。
那么按理说应该是延迟越小，吞吐量就越大啊，感觉像一个目标了，减少了延迟就会增大吞吐量，其实这两个不是一个目标，因为延迟指的是平均延迟，也就是平均响应时间。举个例子就明白了，例如有一大批响应时间短的请求和一大批响应时间长的请求，如果系统每次都先处理响应短的请求，那么就会获得高的吞吐量，但是由于响应时间长的请求总是未得到处理，那么就会造成整个平均响应时间的增加。
4.2显式GC
可通过-XX:+DisableExplicitGC来避免显式Full GC。GC log中带有 System的就是显式的Full GC，由代码中调用System.gc()引起的。但是如果避免显式GC的话，ByteBuffer.allocateDirect()分配的堆外内存无法回收，如果用了这个的话，横竖都是死啊。
4.3避免自动扩展
为了避免内存自动扩展，可以将-Xms和-Xmx，以及-XX:PermSize和-XX:MaxPermSize设置为相同大小，因为如果自动扩展的话会频繁触发Full GC，从而导致容量扩充，所以实际生产环境可以将两个参数设置为相等。
4.4堆大小配置
堆大小配置的通用法则：
Java堆： 3-4倍 Full GC后的老年代空间占用量
永久代： 1.2-1.5倍...
新生代： 1-1.5倍...
老年代： 2-3倍...
4.5垃圾收集器选择
根据不同的应用选择不同的垃圾收集器，如果要获得高的吞吐量使用吞吐量优先收集器，通常调优的话，可以从这个收集器开始，如果达不到应用的要求，替换为其他的收集器。
如果要获得用户和垃圾收集器的并行，获得更小的延迟，那么考虑使用CMS收集器。
如果是单核机器，内存较小(小于100M)，则可使用串行收集器，因为它的算法最简单，在这种场景下性能也最好。
如果堆大小达到10G以上，即使使用UseParallelOldGC并行处理，需要的时间也会比较长，这时候可以考虑使用CMS收集器。
标签：
原文地址：http://www.cnblogs.com/hgfq/p/4318238.html
