Java并发编程实战读书笔记——第十二章 并发程序的测试

测试并发程序的挑战主要是：潜在的错误的发生并不具有确定性，而是随机的。

并发测试大致分为两类：安全测测试与活跃性测试。安全性定义为不发和任何错误的行为，活跃性定义为某个良好的行为终究会发生。

性能测试：吞吐量指一组并发任务中已完成任务所占的比例；响应性：指请求从发出到完成之间的时间（延迟）；可伸缩性：指在增加更多资源的情况下（CPU），吞吐量的提升情况。

12.1 正确性测试

找出需要检查的不变性条件和后验条件。

有界缓存可以直接使用ArrayBlokcingQueue或LinkedBlockingQueue。

BoundedBuffer，其中使用Sempaphore来实现缓存的有界属性和阻塞行为。

12.1.2 对阻塞操作的测试

在java.util.concurrent的一致测试中，一定要将各种故障与特定的测试明确地关联起来。因此JSR166专家组创建了一个基类，其中定义了一些方法可以在tearDown期间传递和报告失败信息，并遵循一个约定：每个测试必须等待它所创建的全部线程结束以后才能完成。

在测试阻塞方法时，只有当线程不再继续执行时，测试才是成功的。当方法被成功地阻塞后，还必须使方法解除阻塞，在线程阻塞后中断它，就可以宣告阻塞操作成功。这要求阻塞方法通过提前返回或者抛出InterruptedException来响应中断。

Thread.getState来验证线程是否在一个条件等待上阻塞是不可靠的。

• 被阻塞线程并不需要进入WAITING或TIMED_WAITING等状态，因此JVM可以选择通过自旋等待来实现阻塞
• 由于Object.wait和Condition.await等方法上存在伪唤醒，因此即使一个线程等待的条件尚未成真，也可能临时地转换到RUNNABLE状态。
• 目标线程在进入阻塞状态时也会消耗一定的时间

它主要作用还是作为调试信息的来源。

12.1.3 安全性测试

在构建对并发类的安全性测试中，需要解决的关键问题在于，要找出那些容易检查的属性，这些属性在发生错误的情况下极有可能失败，同时又不会使得错误检查代码人为地限制并发性。理想情况是，在测试属性中不需要使用任何同步机制。

使用线程内部随机生成的测试数据，避免编译器预行计算出这个结果，在元素入列、出列时计算检验和，并在测试程序运行完成后，检验和是否相同。

这些测试应该放在多处理器的系统上运行，从而进一步测试更多形式的交替运行，然而，CPU的数量越多并不一定会使测试越高效。要最大程序地检测出一些对执行时序敏感的数据竞争，那么测试中的线程数量应该多于CPU数量，这样在任意时刻都会有一些线程在运行，而另一些被交替出去，从而可以检查线程间交替行为的可预测性。

让测试框架放弃那些没有在规定时间内完成的测试。

12.1.4 资源管理的测试

对于任何持有或管理其他对象的对象，都应该在不需要这些对象时销毁对它们的和。这种存储资源泄漏不仅会妨碍垃圾回收器回收内存，而且还会导致资源耗尽以及应用程序失败。BoundedBuffer需要限制缓存大小来来防止资源耗尽。

12.1.5 使用回调

在构造测试安全时，对客户提供的代码进行回调是非常有有助的。

回调函数的执行通常是在对象生命周期的一些已知位置上，并且在这些位置上非常适合判断不变性条件是否被破坏。例如，在ThreadPoolExecutor中将调用任务的Runnable和ThreadFactory。

12.1.6 产生更多的交替操作

活动线程的数量大于处理器的数量可以提高发现错误的概率。

在访问共享状态的操作中使用Thread.yield将产生更多的上下文切换。也可以使用一个睡眠时间较短的sleep，更可靠一些。

会修改源代码，会带来不变，可以考虑使用AOP工具。

12.2 性能测试

性能测试将衡量典型测试用例中的端到端性能。

性能测试的第二个目标是根据经验值来调整各种不同的限值，例如线程数量、缓存 容量。

12.2.1 在PutTakeTest中增加计时功能

记录整个是运行过程的时间，然后除以总操作的数量，从而得到每次操作的运行时间。使用一个栅栏动作来测量启动和结束时间。

• 生产者——消费者模式在不同参数下的吞吐率
• 有界缓存在不同线程数量下的可伸缩性
• 如何选择缓存的大小

通过测试测量生产者和消费者在通过有界缓存传递数据时，哪些约束条件将对整体吞吐量产生影响。

12.2.2 多种算法的比较

双核超线程机器的上的吞吐量测试，缓存大小256个元素。

LinkedBlockingQueue的可伸缩性要高于ArrayBlockingQueue。链表队列的put和take等方法能将队列头节点的更新操作与尾节点的更新操作分离开来，可以支持更高的并发性。同时内存分配操作通常是线程本地的，因此如果算法能通过多执行一些内存分配操作来降低竞争程序，那么这种算法通常具有更高的可伸缩性。

12.2.3 响应性衡量

可预测性，服务时间

记录每个任务的完成时间

非公平的信号量（Shaded Bars）和公平的信号量(开放栅栏，open bars)

非公平的信号量通常能实现更好的吞吐量，而公平的信号量则实现更低的变动性。

12.3 避免性能测试的陷阱

12.3.1 垃圾回收

垃圾回收的执行无法预测，它可能在任何时刻运行。

防止垃圾回收操作对测试产生影响：

• 确保垃圾回收操作在测试运行的整个期间都不会执行(-verbos: gc判断是否执行)
• 确保垃圾回收在测试期间执行多次

12.3.2 动态编译

HotSpot JVM将字节码的解释与动态编译结合起来。当某个类第一次加载时，JVM会通过解译字节码的方式来执行它。在某个时刻，如果一个方法运行的次数足够多，那么动态编译器会将它编译为机器代码，当编译完成后，代码的执行方式将从解释执行变成直接执行。

代码可能被编译：加载了一个使编译假设无效的类或者收集了足够的信息后，决定采用不同的优化措施来重编译某条代码路径。

防止动态编译对测试结果产生偏差：

• 使程序运行足够长的时间，使编译过程以及解释执行都只占一小部分
• 使代码预先运行一段时间不测试这段时间内的代码性能

-XX: +PrintCompilation 动态编译运行时输出这条信息

12.3.3 对代码路径的不真实采样

运行时编译器根据收集到的信息对已编译的代码进行优化。因此一段代码执行过程中，可能产生多种代码路径。多覆盖应用程序中的执行情况，在多线程环境中模拟执行。

12.3.4 不真实的竞争程序

并发的应用程序可以交替执行两种不同类型的工作：访问共享数据以及执行线程本地的计算。根据两种不同类型工作的相关程度，将出现不同程度的竞争，并表现出不同的性能与可伸缩性。

如果有N个线程从共享工作队列中获取任务并执行它们，并且这些任务都是计算密集型的以及运行时间较长，那么这种情况下几乎不存在竞争，吞吐量仅受限于CPU资源的可用性。然而，如果任务周期非常短，那么在工作队列上将会存在严重的竞争，此时的吞吐量将受限于同步的开销。

12.3.5 无用代码的消除

优化编译器能找出并消除那些不会对输出结果产生任何影响的无用代码(Dead Code)。由于基准测试通常不会执行任何计算，因此它们很容易在编译器的优化过程中被消除。

-server模式而不是-client模式，必须保证它们不会受到无用代码消除优化的影响。

要编写有效的性能测试程序，就需要告诉优化器不要将基准测试当作无用代码而优化掉。这就要求在程序中对每个计算结果都要通过某种方式来使用，这种方式不需要同步或者大量计算。

校验和需要使用，不然就会被优化掉。

简单的技术避免被优化并不会引入过高的开销：计算某个派生对象中域的散列值并与一个任意值比较。

12.4 其他的测试方法

测试的目标不是更多地发现错误，而是提高代码能按照预期方式工作的可信度。因为找出所有错误是不现实的。单元测试与性能测试，代码审查与静态分析。

12.4.1 代码审查

多人参与的代码审查，不仅能发现错误，通常还能提高描述实现细节的注释的的质量，因此将降低后期维护的成本和风险。

12.4.2 静态分析工具

静态代码分析是指在进行分析时不需要运行代码，而代码核查工具可以分析类中是否存在一些常见的错误信息。

静态分析工具能生成一个警告列表，其中包含的警告信息必须通过手工方式进行检查。FindBugs等。

12.4.3 面向方面的测试技术

AOP可以用来确保不变性条件不被破坏，或者与同步策略的某些方面保持一致。

12.4.4 分析与监测工具

支持线程监测行为，为每个线程提供了一个时间线显示，并且用颜色来区分不同的线程状态（可运行，由于等待某个锁而阻塞，由于等待I/O操作而阻塞等等）。

小结

要测试并发程序的正确性非常困难，因为并发程序的许多故障模式都是一些低概率事件，它们对于执行时序、负载情况以及其他难以重现的条件都非常敏感。而且，在测试中还可能引入额外的同步或执行时序限制 ，这些因素会掩盖被测试代码中的一些并发问题。动态编译语言测试起来更困难，因为动态编译、垃圾回收以及自动化等操作都会影响与时间相关的测试结果。

传统的测试技术与代码审查和徐步云化分析工具结合起来，每项技术都可以找出其他技术忽略的问题。