1. 前言
最近产品在普通压测下并没有实际问题，但是在实际环境的大数据(日数据量在1.3亿左右)情况下便出现了一些列的性能问题，因此进行一系列的情况调优
当然每种问题处理的方案不一样，这里只是记录个人解决问题的方案与步骤
2. cpu标高
cpu标高问题是由一系列问题导致的，具体可以通过以下两种方案去进行处理：
- 通过
jdk提供的工具去进行处理 - 通过
arthas工具去进行处理
java进程的日志无报错，只是CPU使用率较高的情况，如果有明显的报错那么就可以通过错误日志去进行诊断
2.1 arthas
arthas是由阿里巴巴开源的一个性能诊断工具，这里就不再赘述，直接上演示步骤,具体如下：a. 定位进程
当CPU标高时，可以通过
top指令去查看，如下图：
文章图片
从图中可以看出CPU的总使用率在
2.8%左右，但是从具体的进程来看有的java进程在31%左右当然这肯定是正常的，这里只是举了个例子,每个情况不一样，需要具体分析当然安装了
`htop命令，通过htop命令去查看CPU每个核具体的使用情况，如下：
文章图片
b. 通过top指令定位以后，则可以通过具体的
jps命令去查看占用较多的是哪个进程，如下：
文章图片
可以发现是
log-service目前占用较高，那么就可以查看这个进程的问题c.启动
arthas工具，具体怎么使用这里就不再赘述，如下：
文章图片
这里选择3-log-service进程，输入
dashboard命令便可以看到这个进程的监控信息如下：
文章图片
输入
thread -n 8命令可以查看到cpu使用率最高的八个线程日志，cpu利用率从高到低排列，如下：
文章图片
最后找到自己程序的代码行数，分析这行代码占用性能的原因
2.2 影响
从目前优化的过程来看，主要有两大因素(针对的是自己的系统)比较消耗资源，如下：
- 正则表达式匹配
- 数据库操作
在JAVA中，正则表达式匹配采用的是NFA(Non deterministic Finite Automaton)去进行匹配，该机制在遇到像
+,*等不确定字符串时，会进行 回溯在一些数据量大，且写的正则表达式不是那么合格时，就会进行不断回溯，从而会特别消耗CPU资源
在这里关于具体详情可以推荐一遍他人的博客
B 解决
- 尽量少用不合格的正则去匹配，如果要使用正则，且数据量大的情况下，进行尽量减少回溯
- 尽量少用一些底层是正则表达式实现的字符串拼接方式，例如
String.format
一切的前提都是基于数据量大的情况，数据量小请忽略，2.2.2 数据库 这种理论较为简单，即在一个循环里面频繁操作数据库，如下：
可以用Jmeter等工具去进行性能压测，验证上述结果
for(String ss : aa) {
database_opertor()
}这种方式每循环一次，那么就会操作发送一次数据库连接，在数据量较大的情况下就会特别消耗CPU资源
因此建议将多个数据库连接改为一个或者降低数据库连接方式，如下：
- 查询一次，具体结果可以通过Stream流处理
- 批量新增
- 批量更新
- 批量删除
一切的前提都是基于数据量大的情况，数据量小请忽略，3. GC 关于
可以用Jmeter等工具去进行性能压测，验证上述结果
GC问题，主要是针对JVM一直Full GC问题，在这里也记录一下FullGC过程，具体过程如下：A.问题：
测试人员通过
Grafana监控到Java组件内存一直成上升趋势，那么可能就会存在内存泄露风险，如下图：
文章图片
后来经过一系列分析，可能是
JVM一直在FullGC导致，因此为了验证这个想法，在这里借助了jvisualvm工具去进行分析(在附文中会详细阐述使用该工具)，分析结果如下：
文章图片
发现老年代直接拉满，当老年代拉满后，就会频繁
FullGC,但是经过几轮GC后，发现还是拉满，这个时候就需要分析为什么会存在拉满原因
当我把对应的组件重启后，堆里面old很快爆满，然后频繁FullGC
因此可以用过jmap命令把堆内存中的信息dump下来，如下：jmap -dump:file=filename.dump pid命令执行后会产生一个
filename.dump文件，通过jvisualvm工具分析这个文件，就知道对堆里面对象信息是什么了B.原因
通过
jmap产生的dump文件分析里面都是消费kafka的消息，也就是说old里面都是消费kafka的消息之所以
old爆满，是因为消费kafka消息太多，当第一次启动时，Eden区爆满，经过第一轮YGC,大部分对象还没处理完，因此直接进入了s0区但是由于进入了
s0区的对象超过了s0区容量的一半，因此就不再计算年龄，而是直接从s0进入到老年代，所以经过几次消费old一直处于爆满状态，然后一直FullGC,导致内存一直增长，最后存在内存泄露C.解决
其实上述问题可以看出，其实还是老年代空间较小,我的组件配置为
-Xms6G -Xmx6G -Xmn5G,也就是说我的配置老年代也就只有1G的空间，因此解决方案如下：- 调小消费
kafka的数量，这样数据量降低了也就不存在频繁FullGC情况
这种方案最后放弃了，因为调小了消费的数据量，性能就达不到要求
- 调大堆内存，增加
old空间大小
这种也放弃了，资源有限，不太好做调整了
- 切换
G1垃圾回收器
最终采用的该方案，G1(JAVA 9默认的垃圾回收器就是这，目前我使用的时JAVA 8），该垃圾回收器与默认的垃圾回收器不同，这个并没有物理上的分代，而是将一整块内存，划分成一个个的小内存，并且给内存打上old,eden,s0,s1标记(具体可以自己了解),切换后整体如下：
文章图片
完美解决了我的困扰
这一章主要是阐述Jvisualvm工具的使用
4.1启动在
JAVA_HOME/bin/目录下
文章图片
双击即启动，启动界面如下：
文章图片
4.2.介绍
文章图片
在本地中选择
VisualVM在右边即可看到对应的JVM信息，同时可以在监视中看到对应的区域信息，如下：
文章图片
也可以在线程中看到所有的线程情况，如下：
文章图片
当然也可以安装一个
Visual GC插件查询实时GC情况，安装步骤如4.3所述4.3 插件
介绍如何安装插件1.访问插件更新地址：https://visualvm.github.io/in...
文章图片
- 选择
plguins
文章图片
- 找到
Plugins Centers
文章图片
- 点击后选择对应的
jdk版本插件，我的jdk版本为java8_u40版本
文章图片
jvisualvm，找到 工具-插件，选择编辑，填上对应的jdk插件地址
文章图片
- 找到对应插件安装即可
文章图片
- 安装好后可以点击
Visual GC查看实时GC情况
文章图片
正常情况下，都是将
jar部署在远程机器上，因此想要查看实时GC就可以通过远程连接进行查询一般远程连接有两种方式：
JMX连接
这种方式连接一般只能监控一个java服务
Jstatd连接
这种方式连接可以监控多个java服务
JMX
- 在远程Java服务上配置
JMX连接，如下：
-Djava.rmi.server.hostname=服务器ip -Dcom.sun.management.jmxremote.port=jmx端口 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
- 在
Jvisualvm上新建一个远程连接
文章图片
填写对应的主机名
填写好了如下：
文章图片
- 在连接名上右键选择添加一个
JMX连接
文章图片
端口号要与服务端配置的一样，接下来点击连接即可，当然界面与之前本地是一样的，如下：
文章图片
但是当点开VisualGC时，却显示如下结果：不受此JVM支持，因此可以使用Jstatd进行连接
文章图片
Jstatd
- 在
java服务新建jstatd-all.policy，文件可以放在任意位置,内容如下
// 注意：这里建议写JAVA_HOME的绝对路径 grant codebase "file:${JAVA_HOME}/lib/tools.jar" { permission java.security.AllPermission; };
最后执行jstatd -J-Djava.security.policy=/opt/jstatd.all.policy -p 12345命令，如果出现以下问题，安装下面配置即可
文章图片
最后发现权限不足，因此去进行授权，修改${JAVA_HOME}/jre/lib/security/java.policy文件
permission java.io.FilePermission "/tmp/-", "read"; permission java.util.PropertyPermission "*", "read"; permission java.net.SocketPermission "*", "connect,resolve,accept,listen"; permission java.util.PropertyPermission "*", "read";
在文件中加入上述内容，如下：
文章图片
- 再次执行命令，即可成功
jstatd -J-Djava.security.policy=/opt/jstatd.all.policy -p 端口 -J-Djava.rmi.server.logCalls=true -J-Djava.rmi.server.hostname=远程服务器ip
- 连接
jstatd,右键新建jstatd连接
文章图片
- 最后可以看到所有的组件信息
文章图片
最后随便点开一个组件便可看到对应的GC情况
【性能调优（CPU飙高 FullGC问题处理）】
文章图片
- 最后可以看到所有的组件信息
