![](https://img-blog.csdnimg.cn/20201014180756754.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
问题排查
文章平均质量分 58
千山鸟飞绝,万径人踪灭。
孤舟蓑笠翁,独钓寒江雪。
Hey 锡瑞
这个作者很懒,什么都没留下…
展开
-
Canal实时同步死锁导致CPU飙升
(1)top查看CPU占用情况,可以看到PID为17314的进程CPU占比为502。把CPU都吃完了,前端页面一直很卡(2)定位具体线程:top -H -p PID 看下该进程下线程的情况,可见5201这几个吃了CPU也可以:ps -mp 17314 -o THREAD,tid定位具体线程。下边拿5200或者5201线程来分析(3)拿5201线程ps一下,定位到是canal的问题(4)printf "%x\n" 线程ID: 将需要的线程ID转换为16进制格式js.原创 2021-07-02 23:18:40 · 2198 阅读 · 1 评论 -
一次ThreadLocal造成的内存泄露排查
问题描述:请求一个接口,有时候返回的是上一次的结果,有时候又返回正确,有时候能请求到接口有时候没请求到也返回数据,返回结果不是想要的,造成数据 不一致。很神奇!!!public class ReqContextHolder { private static final ThreadLocal<ReqContext> contextMap = new ThreadLocal<>(); private static final Map<String原创 2021-03-19 19:01:38 · 1459 阅读 · 0 评论 -
ThreadPoolExecutor线程池问题排查:线程池设置不合理导致future.get()阻塞
一、业务背景有一个接口的部分功能使用了线程池,这个功能放在线程池里和主线程并行执行,等线程池里的任务执行完通过future.get的方式(如果需要得到线程池里的线程执行结果,使用future的方式)获取线程池里的线程执行结果,然后合并到主流程的结果里返回给前端。业务场景很简单,目的是不影响主流程的性能,不增加整体响应时间。但是遇到了设计的逻辑错误。设计场景:I/O密集型(大部分业务都是通过调用接口实现的) 核心线程数:4核(cpu核数) 最大线程数:cpu核数*2 等待队列:2048二、相关原创 2020-12-16 18:20:37 · 6872 阅读 · 0 评论 -
代码规范扫描的一些案例
一、sonar代码规范扫描1.1、提示Use try-with-resources or close this "XXX" in a "finally" clause(1)案例1:问题描述:提示我们用java7的try-with-resources模式处理流,免去手动在finally里close等繁琐流程问题解决:例如可以这样try (InputStream inputStream = f.downloadFile(fileName); OutputStre原创 2020-12-02 16:46:51 · 1259 阅读 · 2 评论 -
SpringCloud框架源码EnvironmentDecryptApplicationInitializer冲突解决
问题描述:配置文件需要配置数据库加密密码,采用RSA加密算法,但是统一需要 加{cipher}{rsa}前缀,不加前缀前启动正常。加了前缀后并且已经在代码里边处理替换掉前缀但是仍然报错:java.lang.IllegalStateException: Cannot decrypt: key=spring.datasource.sydev.password at org.springframework.cloud.bootstrap.encrypt.EnvironmentDecryptApplic原创 2020-11-16 11:27:49 · 949 阅读 · 0 评论 -
JVM实战:服务内存溢出问题排查案例1
1.问题呈现钉钉告警群发出rpc调用超时,服务健康检查自动重启。检查CAT发现老年代内存居高步下,pinpoint如下图频繁fullGC 最终将导致服务崩溃重启。2.原因排查 step1: 老年代内存一直居高步下,初步判定是有对象一直没有被回收且一直在增长所以导致内存被耗尽频繁FULL GC。内存出问题就应该从分析内存下手,由于加入健康检查,当服务在30s内无反应会自动重启服务。因此之前设置的HeapDumpOnOutOfMemoryError 发生OOM自动dump...原创 2020-06-12 10:49:45 · 872 阅读 · 0 评论