切换菜单
搜索
个人笔记云
首页
java
spring
springmvc
python
使用教程
笔记管理
搜索
登录/注册
好物分享
退出
搜索
Java性能调优
2021-10-01
990
**参考视频教程:** [**从零开始学调优-java 全技术栈 性能调优 **](http://www.notescloud.top/goods/detail/1305) JVM调优(最关键参数为:-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold) 代大小调优: 避免新生代大小设置过小、避免新生代大小设置过大、避免Survivor设置过小或过大、合理设置新生代存活周期。 -Xmn 调整新生代大小,新生代越大通常也意味着更多对象会在minor GC阶段被回收,但可能有可能造成旧生代大小,造成频繁触发Full GC,甚至是OutOfMemoryError。 -XX:SurvivorRatio调整Eden区与Survivor区的大小,Eden 区越大通常也意味着minor GC发生频率越低,但可能有可能造成Survivor区太小,导致对象minor GC后就直接进入旧生代,从而更频繁触发Full GC。 GC策略的调优:CMS GC多数动作是和应用并发进行的,确实可以减小GC动作给应用造成的暂停时间。对于Web应用非常需要一个对应用造成暂停时间短的GC,再加上Web应用 的瓶颈都不在CPU上,在G1还不够成熟的情况下,CMS GC是不错的选择。 (如果系统不是CPU密集型,且从新生代进入旧生代的大部分对象是可以回收的,那么采用CMS GC可以更好地在旧生代满之前完成对象的回收,更大程度降低Full GC发生的可能) 在调整了内存管理方面的参数后应通过-XX:PrintGCDetails、-XX:+PrintGCTimeStamps、 -XX:+PrintGCApplicationStoppedTime以及jstat或visualvm等方式观察调整后的GC状况。 出内存管理以外的其他方面的调优参数:-XX:CompileThreshold、-XX:+UseFastAccessorMethods、 -XX:+UseBaiasedLocking。 程序调优 CPU消耗严重的解决方法 CPU us高的解决方法: CPU us 高的原因主要是执行线程不需要任何挂起动作,且一直执行,导致CPU 没有机会去调度执行其他的线程。 调优方案: 增加Thread.sleep,以释放CPU 的执行权,降低CPU 的消耗。以损失单次执行性能为代价的,但由于其降低了CPU 的消耗,对于多线程的应用而言,反而提高了总体的平均性能。 (在实际的Java应用中类似场景, 对于这种场景最佳方式是改为采用wait/notify机制) 对于其他类似循环次数过多、正则、计算等造成CPU us过高的状况, 则需要结合业务调优。 对于GC频繁,则需要通过JVM调优或程序调优,降低GC的执行次数。 CPU sy高的解决方法: CPU sy 高的原因主要是线程的运行状态要经常切换,对于这种情况,常见的一种优化方法是减少线程数。 调优方案: 将线程数降低 这种调优过后有可能会造成CPU us过高,所以合理设置线程数非常关键。 对于Java分布式应用,还有一种典型现象是应用中有较多的网络IO操作和确实需要一些锁竞争机制(如数据库连接池),但为了能够支撑搞得并发量,可采用协程(Coroutine)来支撑更高的并发量,避免并发量上涨后造成CPU sy消耗严重、系统load迅速上涨和系统性能下降。 在Java中实现协程的框架有Kilim,Kilim执行一项任务创建Task,使用Task的暂停机制,而不是Thread,Kilim承担了线程调度以及上下切换动作,Task相对于原生Thread而言就轻量级多了,且能更好利用CPU。Kilim带来的是线程使用率的提升,但同时由于要在JVM堆中保存Task上下文信息,因此在采用Kilim的情况下要消耗更多的内存。(目前JDK 7中也有一个支持协程方式的实现,另外基于JVM的Scala的Actor也可用于在Java使用协程) 文件IO消耗严重的解决方法 从程序的角度而言,造成文件IO消耗严重的原因主要是多个线程在写进行大量的数据到同一文件,导致文件很快变得很大,从而写入速度越来越慢,并造成各线程激烈争抢文件锁。 常用调优方法: 异步写文件 批量读写 限流 限制文件大小 内存消耗严重的解决方法 释放不必要的引用:代码持有了不需要的对象引用,造成这些对象无法被GC,从而占据了JVM堆内存。(使用ThreadLocal:注意在线程内动作执行完毕时,需执行ThreadLocal.set把对象清除,避免持有不必要的对象引用) 使用对象缓存池:创建对象要消耗一定的CPU以及内存,使用对象缓存池一定程度上可降低JVM堆内存的使用。 采用合理的缓存失效算法:如果放入太多对象在缓存池中,反而会造成内存的严重消耗, 同时由于缓存池一直对这些对象持有引用,从而造成Full GC增多,对于这种状况要合理控制缓存池的大小,避免缓存池的对象数量无限上涨。(经典的缓存失效算法来清除缓存池中的对象:FIFO、LRU、LFU等) 合理使用SoftReference和WeekReference:SoftReference的对象会在内存不够用的时候回收,WeekReference的对象会在Full GC的时候回收。 资源消耗不多但程序执行慢的情况的解决方法 降低锁竞争: 多线多了,锁竞争的状况会比较明显,这时候线程很容易处于等待锁的状况,从而导致性能下降以及CPU sy上升。 使用并发包中的类:大多数采用了lock-free、nonblocking算法。 使用Treiber算法:基于CAS以及AtomicReference。 使用Michael-Scott非阻塞队列算法:基于CAS以及AtomicReference,典型ConcurrentLindkedQueue。 (基于CAS和AtomicReference来实现无阻塞是不错的选择,但值得注意的是,lock-free算法需不断的循环比较来保证资源的一致性的,对于冲突较多的应用场景而言,会带来更高的CPU消耗,因此不一定采用CAS实现无阻塞的就一定比采用lock方式的性能好。 还有一些无阻塞算法的改进:MCAS、WSTM等) 尽可能少用锁:尽可能只对需要控制的资源做加锁操作(通常没有必要对整个方法加锁,尽可能让锁最小化,只对互斥及原子操作的地方加锁,加锁时尽可能以保护资源的最小化粒度为单位--如只对需要保护的资源加锁而不是this)。 拆分锁:独占锁拆分为多把锁(读写锁拆分、类似ConcurrentHashMap中默认拆分为16把锁),很多程度上能提高读写的性能,但需要注意在采用拆分锁后,全局性质的操作会变得比较复杂(如ConcurrentHashMap中size操作)。(拆分锁太多也会造成副作用,如CPU消耗明显增加) 去除读写操作的互斥:在修改时加锁,并复制对象进行修改,修改完毕后切换对象的引用,从而读取时则不加锁。这种称为CopyOnWrite,CopyOnWriteArrayList是典型实现,好处是可以明显提升读的性能,适合读多写少的场景, 但由于写操作每次都要复制一份对象,会消耗更多的内存。
教程分类
热门视频教程
热门文章
热门书籍推荐