JMeter测试并发场景，是通过设置Synchronizing Timer（同步定时器），熟悉LoadRunner性能测试的话，就知道里面有个概念：集合点。
Synchronizing Timer则可以理解为集合点的作用。
Synchronizing Timer的设置策略很简单：
- Number of Simulated Users to Group by：意思是按组模拟用户数，也就是设置组的用户数（并发数），当线程组Thread Strated达到该值时，同步执行请求。默认为0，即当前线程组的所有线程数。
- Timeout in milliseconds：超时时间（单位：毫秒），组在超时时间后达不到设置的线程数时，会丢弃继续请求，释放已达到的线程。默认为0，即无超时限制，会一直等待。
下面以一张图，理解Synchronizing Timer：
假设存在这样的一个场景：一个线程组有3个线程，Ramp-Up Period为30s，循环次数为1（可忽略，因为不影响请求）。
为线程组添加一个默认的集合点，即使Number of Simulated Users to Group by和Timeout in milliseconds都为0。
那么由Log Viewer跟踪分析，运行结果图：
第1个线程，在点击运行时就启动（Thread strated：Thread Group 1-1），但未运行（即没有发送HTTP请求），然后等到第10s，第2个线程马上启动（Thread strated：Thread Group 1-2），然后等到第20s时，马上启动第3个线程（Thread strated：Thread Group 1-3），接着线程Thread Group 1-1、Thread Group 1-2、Thread Group 1-3在第20s同时运行.....在接下来的运行时间里，无论什么时候有其中一个线程运行失败，则会无期限地等待.....这就会带来运行卡住的问题。
问题来了，如果设置Synchronizing Timer的运行策略，即能保证性能测试正常执行，又能真实的反映性能结果？
我们必须保证对Synchronizing Timer的设置有效且有意义：
1.对Number of Simulated Users to Group by有效设置：
并发用户数<=总线程数
2.Timeout in milliseconds有效设置：
超时公式：并发线程数* Ramp-Up Periond(in seconds)/总线程数
当并发线程数=总线程数时，则超时时间等于Ramp-Up Periond(in seconds)
但，当超时时间<并发线程数*Ramp-Up Periond(in seconds)/总线程数 时，启动执行，则会一直提示：“WARN - jmeter.timers.SyncTimer: SyncTimer Synchronizing Timer timeouted waiting for users after:10ms”，此时的设置会影响性能结果，如图：
结论：
JMeter通过添加Synchronizing Timer（同步定时器）来实现线程并发，Synchronizing Timer的设置策略中要保证Synchronizing Timer的设置有效且有意义，那么要设置并发用户数<=总线程数，且超时时间设置>=并发线程数*Ramp-Up Periond(in seconds)/总线程数。