synchronized带来的问题 20110330

很早就想弄个博客，与朋友们一起探讨技术。

 

就从一个客户的某个系统上线前的一点小问题谈起吧。

 

其实不算调优，算系统上线前的一个小插曲。 客户的技术人员Ｗ来邮件，说他们的PLM系统上线前用LoadRunner做压力测试时，出现了一个奇怪的现象。前两个小时内，ART比较平稳，始终在3-6秒之间。可2个小时过后，ART快速攀升到40-60秒，最高达100秒以上，且抖动得非常厉害。 未去之前的第一个感觉就是资源占用，出现了竞争。

 

到达现场，了解了系统运行环境。从JVM参数设置、应用服务器配置和数据库配置等方面进行了初步检查。发现JVM的内存回收策略存在一定问题，其它方面正常。调整了回收策略及其它相关参数后，系统性能略有10%以上的提升，但没从根本上解决问题。

 

通过Wily监测到执行缓慢的Top 10个JSP，结合业务调用逻辑和时间分析，发现每次压力测试2个小时后，基本处于同一时刻，部分页面运行突然变得缓慢。对调用栈进行逐个分析，发现执行时间激增的代码段对应有大量synchronized(session)和synchronized(request)代码。回头检查了客户的压力测试脚本，发现Vuser仅为1个。于是确认是同步块导致的问题。将Vuser参数化为实际最大并发数后重新运行压力测试程序，问题不再。

 

synchronized本用于同步控制，但不合理的压力测试脚本导致同一用户在多个并发访问时遭遇到了麻烦。虽然此例实际运行时不会出现这样的问题，但告诉我们慎用synchronized。我曾经看到某个客户的ERP系统中，最关键的获取经过封装的数据库连接处不恰当地使用了synchronized，导致并发量一上升就成了性能瓶颈。

 

大家可以回头看看Java编程中的单例模式的某种实现，想想synchronized为什么放在那个位置。