|
快捷键一次你记不住，多来几次你总能记住了吧?
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
（编辑：晋中站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
