阿里员工排查问题的工具清单，总有一款适合你！

快捷键一次你记不住，多来几次你总能记住了吧?

maven helper

分析maven依赖的好帮手。

VM options 

1、你的类到底是从哪个文件加载进来的?

-XX:+TraceClassLoading 
结果形如[Loaded java.lang.invoke.MethodHandleImpl$Lazy from D:programmejdkjdk8U74jrelibrt.jar] 

2、应用挂了输出dump文件

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/logs/java.hprof 

jar包冲突 

把这个单独写个大标题不过分吧?每个人或多或少都处理过这种烦人的case。我特么下边这么多方案不信就搞不定你?

mvn dependency:tree > ~/dependency.txt 

打出所有依赖

mvn dependency:tree -Dverbose -Dincludes=groupId:artifactId 

只打出指定groupId和artifactId的依赖关系

-XX:+TraceClassLoading 

vm启动脚本加入。在tomcat启动脚本中可见加载类的详细信息

-verbose 

vm启动脚本加入。在tomcat启动脚本中可见加载类的详细信息

greys:sc 

greys的sc命令也能清晰的看到当前类是从哪里加载过来的

tomcat-classloader-locate 

通过以下url可以获知当前类是从哪里加载的

curl http://localhost:8006/classloader/locate?class=org.apache.xerces.xs.XSObjec 

其他 

dmesg

如果发现自己的java进程悄无声息的消失了，几乎没有留下任何线索，那么dmesg一发，很有可能有你想要的。

sudo dmesg|grep -i kill|less 

去找关键字oom_killer。找到的结果类似如下:

[6710782.021013] java invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_scoe_adj=0 
[6710782.070639] [<ffffffff81118898>] ? oom_kill_process+0x68/0x140  
[6710782.257588] Task in /LXC011175068174 killed as a result of limit of /LXC011175068174  
[6710784.698347] Memory cgroup out of memory: Kill process 215701 (java) score 854 or sacrifice child  
[6710784.707978] Killed process 215701, UID 679, (java) total-vm:11017300kB, anon-rss:7152432kB, file-rss:1232kB 

以上表明，对应的java进程被系统的OOM Killer给干掉了，得分为854.

解释一下OOM killer(Out-Of-Memory killer)，该机制会监控机器的内存资源消耗。当机器内存耗尽前，该机制会扫描所有的进程(按照一定规则计算，内存占用，时间等)，挑选出得分最高的进程，然后杀死，从而保护机器。

dmesg日志时间转换公式:

log实际时间=格林威治1970-01-01+(当前时间秒数-系统启动至今的秒数+dmesg打印的log时间)秒数：

date -d "1970-01-01 UTC `echo "$(date +%s)-$(cat /proc/uptime|cut -f 1 -d' ')+12288812.926194"|bc ` seconds" 

剩下的，就是看看为什么内存这么大，触发了OOM-Killer了。

新技能get 

RateLimiter

想要精细的控制QPS? 比如这样一个场景，你调用某个接口，对方明确需要你限制你的QPS在400之内你怎么控制?这个时候RateLimiter就有了用武之地。详情可移步http://ifeve.com/guava-ratelimite

（编辑：大同站长网）

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