并发测试：安全性测试(正确性测试)、活跃性测试(与之相关的是性能测试：吞吐量、响应性、可伸缩性)
测试代码同样会对执行时序或同步操作带来影响，这可能会掩盖一些可以暴露的错误。
本章节手写一个并发队列BoundBuffer作为被测样例
1. 正确性测试当我们测试BoundBuffer在put()、take()行为是否正确(是否正确放映元素个数变化、触摸边界时候是否正确阻塞)时，可以借助Samaphore来实现对其元素个数的监听 以及 对边界情况阻塞 的效果。
设想一下，如果被测程序在临界条件下正确进入阻塞状态之后，应该要如何通知到外部测试程序呢？ 方案一(不建议)： 使用Thread.getState来校验被测程序是否进入WAITING或TIMED_WAITING状态。 弊病： JVM有可能并没有使被阻塞线程真的挂起，而是使其自旋。(略扯一点：object.wait、condition.await都会出现'伪唤醒'的情况) 即便忽视这种情况，被测程序进入到阻塞状态的过程也会消耗一定的时间 方案二(简单可控)： 测试程序在被测程序进入阻塞后，中断其阻塞状态 难点： 测试程序需要把握中断的时机(需要sleep多久之后执行中断) 还可以使用限时的join保证中断后的被测程序即便是遭遇意料之外的情况，也能返回结果
基于方案二的实现;
由于测试程序本身也是并发程序，这使得测试程序的开发变得困难。为了不干扰被测程序的线程调度，理想的情况是，不对测试的属性使用任何同步机制。
像本案中的BoundBuffer的并发正确性测试，我们在测试程序可以使用产消模型的方式来测试放入、取出队列的各个元素。
实现方式： 方案一(不建议)： 准备一个队列的副本，每次修改队列时，同步修改到副本 待被测程序运行结束之后，通过比较副本队列来验证其正确性 弊病： 副本需要同步队列的修改，这会干扰被测程序的线程调度 方案二(逻辑更加简单)： 归纳到串行环境的测试上: 按一定顺序 产出 一系列已知的元素的元素 待被测程序运行结束之后，检查消费顺序是否按照原先 产出 的顺序 推广到并发环境的测试上： 由于并发执行的时序不可知 -> 我们不再关心消费的顺序 -> 转而关心是否 产出多少 就 消费多少 待被测程序运行结束之后，校验其 产出/消费 总和 -> 借助原子变量的可见性实现 -> 尽量的减少对线程调度的干扰 需要考虑的实际问题： ”聪明“的编译器早就猜到了这个总和 -> 每个线程都私有一个随机数生成器 -> 建议使用更加简单的、静态的、线程间通用的伪随机数生成函数 很多随机数生成器都是线程安全的 -> 带来额外的同步开销 被测程序中线程交替执行的激烈程序有限 -> 很可能先初始化好的线程先执行 -> 使用闭锁、栅栏缓解这种问题 线程的创建、启动都需要不小的开销 被测程序的线程数应该要多于CPU数量 -> 激化数据竞争 并发程序测试需要注意错误、异常的抛出 -> 程序可能无法在规定时间内结果 -> 测试程序需要对执行时间敏感
列举一个伪随机数生成函数
方案二的测试代码：
生产者&消费者实现代码：
