快被系统性能逼疯了？你需要这份性能优化策略

升级log4j组件到log4j2，参考log4j2官方文档，配置合理的日志缓冲区，采用高效的Appenders，比如RollingRandomAccessFile。但log4j2仍然采用同步日志，不采用异步日志。因为网银系统日志量较大，异步日志队列很快就满了，如果单条日志存在大报文，还有可能导致内存溢出，因此不适合采用异步日志。如果日志量少（压测产生日志的速度，低于日志写入文件的速度），则可以使用异步日志，大幅提高性能。如果日志量较大，则不建议使用异步日志。

排查方法：

• JVM启动参数中增加-XX:+HeapDumpOnCtrlBreak，压测进行时，kill -3 pid 杀几个javacore，使用jca457.jar工具打开并分析。推荐使用该工具，因为该工具可以对所有线程状态进行统计，并生成饼状图，方便查看。

• 压测进行时，使用jvisualvm获取jvm快照，分析线程堆栈。

4、多线程并发问题

问题现象：采用合理的并发数压测，系统出现逻辑错误、交易失败或异常报错。经查是由于对象中变量被异常修改导致。

问题原因：系统中全局对象中的类变量或全局对象，被多个线程修改。

解决方法：排查系统中所有持有全局对象或类变量的代码，检查其全局变量是否可能被多个线程并行修改。

修改方法：

• 将全局变量转成方法内的局部变量；

• 对全局变量进行同步控制比如syncronized代码块，或者java.util.concurrent锁。

排查方法：并发问题很可能是由全局变量或者对象导致，准确识别全局变量，通过阅读代码找问题。建议应用梳理所有可能存放全局对象的代码，统一管控，或者把所有全局对象放到一个类中，方便管理。

5、打开了太多文件

问题现象：采用合理的并发数压测，交易失败，或后台日志报错：To many open files。

问题原因：

• 读取配置文件或者业务数据文件后，未关闭文件流；

• /etc/security/limits.conf中最大打开文件数配置过小。

解决方法：

• 使用lsof –p pid 命令查看进程打开的文件，如果大部分文件都是同一类型的文件，说明可能未关闭文件流。找到打开文件的代码，关闭文件流即可。

• 如果不存在未关闭文件流的问题，且业务本身就需要处理大量文件，则修改/etc/security/limits.conf文件如下内容：

* hard nproc 10240

* soft nproc 10240

6、内存泄漏

问题现象：JVM内存耗尽，后台日志抛出OutOfMemeryError异常 ；

问题原因：内存溢出问题可能的原因比较多，可能是全局的List、Map等对象不断被扩大，也可能是程序不慎将大量数据读到内存里；可能是循环操作导致，也可能后台线程定时触发加载数据导致。

解决方法：对于ibmjdk纯java应用，在jvm启动时设置-XX:+HeapDumpOnOutOfMemory Error参数，会在内存溢出时生成heapdump文件。使用ha456.jar工具打开heapdump文件，分析大对象是如何产生的。

当然，在heapdump中对象类型可能只是List这种结构，看不出具体哪个业务代码创建的对象。此时要分析所有的全局对象，列出可疑的List或Map对象，排查其溢出原因。

全局对象、引用的初始化、修改要慎重。建议应用梳理所有可能存放全局对象的代码，统一管控。

7、JVM垃圾回收频繁

问题现象：top –H –p pid命令查看，GC Slave线程CPU占用排名始终为前三名，同时Jconsole查看jvm内存占用较高，垃圾回收频繁。使用ga456.jar分析gc日志，查看gc频率、时长。

打印gc日志的方法：在jvm启动参数里增加-verbose:gc -Xverbosegclog:/usr/ebank/ logs/cobp/gcdetail.log

问题原因：高并发下，内存对象较多，jvm堆内存不够用 。

解决方法：扩大堆内存大小–Xmx2048m –Xms2048m。

8、CPU高

问题现象：50并发压测，监控工具显示bp、前置CPU占用90%以上。

问题原因：业务处理中存在大量CPU计算操作。

（编辑：安卓应用网_ASP源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!