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收集器。
《Java性能优化权威指南》
jenkins jvm 优化 jvm的优化
转载本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。
![](https://ucenter.51cto.com/images/noavatar_middle.gif)
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
JVM参数的优化
级的垃圾回收), 释放后若Eden空间仍然不足以放入
java jvm 内存 tomcat url -
JVM编译优化
参考文章: 方法内联: https://www.toutiaium=toutiao_ios&wxshare_count=1 整体描述: htt.
JVM Java Client Server 编译器