场景：
大家在使用Jmeter测试的时候应该发现了，
（1）线程启动了就会直接发送测试请求；--如果要模拟在一瞬间高并发量测试的时候，需要调高线程数量，这很耗测试机器的性能，往往无法支持较大的并发数，无法控制每次测试的瞬间并发量；
（2）如果使用了constant throughput timer，可以模拟较长时间的并发测试，但是仍无法满足稳定的瞬间高并发测试；
解决：
1、使用集合点；
作用：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力。
引用虫师的话“红军排长说：等一等！集结了所有战友后，大家再一起冲啊！这样给敌人的压力是最大的。”
操作步骤
1、添加集合点，在Jmeter里是synchronized timer；
4、添加相关请求，结果树等，运行查看效果
通过结果树可以看到，请求是批量执行的；
1）开始执行的脚本，观察请求的增加数量趋势；
或
2）对比请求的发送时间；
4、其他实践
（1）实践1--synchronizing timer应用于多个sampler中的其中一个
如果希望定时器仅应用于其中一个sampler，则把该定时器作为子节点加入，如下图
定时器仅仅对其上的HTTP请求1起作用，即仅在HTTP请求1执行前执行定时器，和HTTP请求2无关。
（2）实践2--synchronizing timer应用于多个sampler
如下，执行HTTP请求1和HTTP请求2前都会执行同步定时器1、2。当执行一个sampler之前时，和sampler处于相同作用域的定时器都会被执行；
注意点
1、网上部分人说“集合点的位置一定要在Sample(采样器）之前才能生效。”
此言差矣，在Jmeter中，timer是在sampler之前执行的。不管这个定时器的位置放在sampler之后，还是之前。当然，如果有多个timer的时候，在相同作用域下，会按上下顺序执行timer，这个就需要慎重放置timer的顺序；
不过，为了更好的可读性，还是建议将timer放在对应的sampler前面 或 子节点中；
2、Synchronizing timer 仅作用于同一个JVM中的线程。
所以，如果使用并发测试，确保"Number of Simultaneous Users to Group by"中设置的值不大于它所在线程组包含的用户数。
（原文：Synchronizing timer blocks only within one JVM, so if using Distributed testing ensure you never set "Number of Simultaneous Users to Group by" to a value superior to the number of users of its containing Thread group considering 1 injector only）
试想：a.如果分布式测试时，synchronizing timer作用于所有jvm，那么jvm之间或者说监控jvm工作的部件就需要频繁通讯，确定线程的数量及状态等，然后集结了足够的线程后，又要发送信号让Jmeter来发送测试请求，中间存在延时，这样就无法模拟更真实的高并发了，而且这个东西还会消耗测试机器的一部分性能，会给测试结果带来负面影响；
所以暂时是只支持控制单个jvm，如果后面有办法解决上面那些问题后，就可以实现控制多个jvm，控制总并发量；
b.如果分布式测试，并使用了Synchronizing timer，且设置的值是小于单个jvm的线程数量；
但是，较难确保所有jvm都在同一时间点集结了同样数量的线程数，这样就很难下测试结论了，因为都不知道是多少并发下的性能表现；当然了，可以将线程的启用时间拉长，并将超时时间延长，这样就很可能会与同一时刻集结到足够的线程，达到超高并发的测试；
所以，分布式测试与Synchronizing timer一般不是同时使用的；如果非要用，则需要慎重设置相关参数；
3、如果设置Timeout in milliseconds为0，且线程数量无法达到"Number of Simultaneous Users to Group by"中设置的值，那么Test将无限等待，除非手动终止。
这个无法达到的情况有如下几种：
a.设置的值大于线程数量，这样就永远无法达到了；
b.最后一批线程数不够集合点数目；