ck_2016

1 常见的JVM参数 -XX:MaxTenuringThreshold：对象晋升老年代的阈值，默认值15（并不是绝对的，如果在Survivor空间中相同年龄所有对象大小的综合大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代）-XX:MaxPermSize~~：永久代大小 Read More

一般对于内存泄漏导致OOM的，可以通过MAT在OOM时生成的dump中查看老年代贡献最大的对象，定位问题代码。但对于老年代缓慢增长FGC又能被回收的，排查会相对麻烦，可以按如下方式进行尝试。 1. 添加GC参数，打出对象分布 -XX:+PrintTenuringDistribution 2022-0 Read More

转自：https://github.com/vipshop/vjtools/tree/master/vjmap Read More

（1） 首先执行命令，查找文件节点号 ls -i 在文件前面会出现的数字就是文件的节点号。 （2）执行命令，就可以把乱码文件删掉了 find -inum 节点号 -delete 转自：https://blog.csdn.net/ljfrocky/article/details/78434218 Read More

各gc的行为（包括各种gc在哪个节点花费的时间最多）及适用场景，应先理解这些前提，分析gc日志才会事半功倍，核心参数解析参见java垃圾回收及gc全面解析（全面覆盖cms、g1、zgc、openj9） 开启gc日志选项：-XX:+PrintGC -XX:+PrintGCApplicationStop Read More

生产环境上，或者其他要测试 GC 问题的环境上，一定会配置上打印GC日志的参数，便于分析 GC 相关的问题。但是可能很多人配置的都不够“完美”，要么是打印的内容过少，要么是输出到控制台，要么是一个大文件被覆盖，要么是……本文带你一步一步，配置一个完美的 GC 日志打印策略 打印内容 为了保留足够多的 Read More

1 调用bean中的某个方法： #抓取 'io.dropwizard.metrics5.ScheduledReporter.report()'tt -t io.dropwizard.metrics5.ScheduledReporter report params.length==0 -n 1 #tt Read More

pmap 首先使用pmap观察内存情况 sudo -u deploy pmap 39 | sort -nk2 | less 可以看到有大量约64M的内存分配： 这个是glibc的feature（http://codearcana.com/posts/2016/07/11/arena-leak-in- Read More

遇到了一个 glibc 导致的内存回收问题，查找原因和实验的的过程是比较有意思的，主要会涉及到下面这些： Linux 中典型的大量 64M 内存区域问题 glibc 的内存分配器 ptmalloc2 的底层原理 如何写一个自定义的 malloc hook 动态链接库 so glibc 的内存分配原理 Read More

（1）查看Java进程中CPU过高线程 查看消耗最高进程 -> pid top shift+h 导出java运行的线程信息 #查看java进程id jps #到处java 进程堆栈信息 jstack <pid> jstack <pid> > ps.txt jstack -l <pid> 找到最耗时的 Read More