初心不改

之所以说内存存在碎片化现象就是根据 used 和 capacity 的数据得来的，上面说了元空间的分配以 chunk 为单位，即使一个 ClassLoader 只加载1个类，也会独占整个 chunk，所以当出现 used 和 capacity 两者之差较大的时候，说明此时存在内存碎片化的情况。真正的问题是，程序猿在错误的地方和错误的时间花了太多的时间担心效率问题；当然，更重要的是，大部分的应用 QPS 都不到10，数据量不到几万，这种低压环境下，想让 JVM 出问题，说实话也挺难的。

top 查找cpu占用高的进程ps 找到对应进程的pidtop -H -p pid 查找cpu利用率较高的线程printf ‘%x\n’ pid 将线程pid转换为16进制得到 nidjstack pid |grep ‘nid’ -C5 –color 在jstack中找到对应堆栈信息进行分析。

当前系统负载的平均值，后面的三个值分别为1分钟前、5分钟前、15分钟前进程的平均数，一般的可以认为这个数值超过 CPU 数目时，CPU 将比较吃力的负载当前系统所包含的进程。注意:上面两个YGCT,FGCT是新生代和老年代各自执行的gc的总的时间,如果需要算Full GC平均时间,则需要用FGCT/FGC,如果平均时间大于1s,则需要考虑优化了.然而,在某些情况下日志反应不了对应的问题,我们就需要自己进行排查,也是本篇文章所写目的所在.在排查时主要有三个步骤,机器层面,进程层面和线程层面.

系统设计之初，每次来新请求，业务层会先查询数据库，判断是否存在相同的id数据（id是唯一标识产品的），有则返回当前数据库查到的数据，根据数据决定下一步动作，没有则认为是初次请求，将数据存入数据库，执行另一个操作。结果最近出现了并发情况下数据库产生了多条重复的数据。这里记录一下相关的思考与解决。