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

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

8月前
1654028

在为客户进行性能诊断调优时,碰到了一个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倍。

请先登录,再评论

直接去掉synchronized不会出现业务上的影响?

8月前
回复 victory_shen:

谨慎使用synchronized,如果没有多线程修改静态变量或单例属性这类需求就不要用,如果有需要也建议只锁必要的代码块,而不是锁整个方法

7月前回复

👍

8月前

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得