性能文章>记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查>

记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查原创

3年前
20061515

在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLand性能分析平台,通过文章主要希望跟大家分享下分析和优化思路以及注意点,有兴趣深入了解的同学可以评论交流。

现象

在执行单接口负载“判断登陆是否正常接口”测试时候,发现10用户增加至50用户并发,TPS保持不变,响应时间处于持续递增状态,应用CPU为27%,数据库CPU为3%,资源消耗维持稳定状态,由此判断应用程序可能存在瓶颈。
1.png
2.png
3.png

分析

通过XLand分析平台线程分析,发现某线程存在锁等待情况,通过XLand中的x分析定位,发现AuthProvider类中getAccessor方法有Synchronized关键字,当两个以上线程同时调用该同步方法时,每次只能有一个线程能进入该方法,其他线程必须等前一个线程执行完该同步方法后,才能有机会进入。
马赛克4.png
5.png

风险点

Synchronized关键字解决的是多个线程之间访问资源的同步性,Synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。谨慎使用Synchronized关键字,以防导致不必要的线程阻塞,影响响应时间。

优化建议

把AuthProvider类中的Synchronized关键字去掉,发现在10用户并发下判断登陆是否正常接口TPS由原来的174笔/秒增长至624笔/秒,增长了3倍。

点赞收藏
电梯战神
请先登录,查看5条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

随机一门技术分享之Netty

随机一门技术分享之Netty

从 Linux 内核角度探秘 JDK MappedByteBuffer

从 Linux 内核角度探秘 JDK MappedByteBuffer

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

15
5