java 测试线程_Java 线程（5）- 性能测试

Ottawa, Canada by @marcojodoin

Avoid premature optimization. First make it right, then make it fast - if it is not already fast enough

衡量性能的指标

响应时间(Responsiveness)，程序或服务对一个相关请求的相应时间

吞吐量(Throughout)，程序或服务单位时间内可以完成的工作量

伸缩性(Scalability)，当增加计算资源(如: CPUs, memory, storage, or I/O bandwidth)后, 可以提高多少吞吐量

Amdahl定理

Amdahl's law describes how much a program can theoretically be sped up by additional computing resources, based on the proportion of parallelizable and serial components.

：通过添加计算资源(如CPUs, memory)，程序或应用可获得的加速速率

：程序或应用中不可并行化的部分所占的比率

：计算资源的数量

当

无限大时，

与

成反比， 也就是如果程序或应用中大部分是不可并行执行的，即使增加再多的计算资源， 程序的性能也不可能获得很大的提升。相反，如果程序中的任务完全可并行执行，即

(现实世界中，这样的程序是不存在的， 任何一个程序中都含有一些不可并行化的部分)，那么

，即可通过增加计算资源，来获得很大的性能提升。因此， 仔细的分析程序中不可并行化的部分(如一些隐含的不可并行的部分：从任务队列中取任务，计算结果的汇集，等)对性能提升是很重要的。

影响线程开销的因素

上下文切换(Context switching)，线程的上下文切换是线程状态由 blocked 变为 running 或由 running 变为 blocked 的引起的，主要来自操作系统或JVM 对进程或线程调度的开销，过度的上下文切换会导致程序性能的低下，其中 IO 操作最容易引起上下文切换，因此应尽量分离 IO 操作，一个好的经验法则是，上下文切换的时间应该在 0.5 ms 到几微秒之间

内存同步(Memory synchronization)，为了使内存同步，常用的方法要么串行化程序，而过度的串行化会影响程序的吞吐量，要么使用锁，而不当的加锁(不要担心正常的使用锁，JVM 对此已经优化的足够好了)，可能带来锁竞争的问题，该问题不但影响程序的吞吐，同时还会影响程序的性能。影响锁竞争的因素包括：锁被请求的频率和锁被持有的时间，根据 Little 定律如果两者的乘积足够小，那么程序的性能会得到很好的提高，因此，可以改善程序的方法包括：

减小锁被持有的时间，即缩小锁的范围，快进快出，尽可能的缩小 synchronized 块的范围，尤其是在保证程序正确的情况下， 尝试把计算和阻塞(如I/O)操作移出 synchronized 块

减小锁被请求的频率，如对不相关的独立状态变量，用不同的锁进行守护、尝试将一个容器(如：ConcurrentHashMap)进行拆分，然后使用不同的锁对拆分后的片段进行守护， 但该技术有一定的副作用，如：很难对整个容器进行加锁，因此可能在一定程度上带来可见性的问题、避免在频繁调用的代码上加锁和避免使用排他锁(Exclusive Locks)

阻塞(Blocking)，主要来自对资源、锁或 I/O 的竞争

测试

The goal of testing is not so much to find errors as it is to increase confidence that the code works as expected

制定测试计划

What do you mean by "faster"? (预期)

Under what conditions will this approach actually be faster? Under light or heavy load? With large or small data sets? Can you support your answer with measurements? (条件)

How often are these conditions likely to arise in your situation? Can you support your answer with measurements? (测量)

Is this code likely to be used in other situations where the conditions may be different? (环境)

What hidden costs, such as increased development or maintenance risk, are you trading for this improved performance? Is this a good trade off? (隐含的代价)

测试的方法

基本的单元测试(保证基本的功能正确)

测试阻塞操作(设定等待时间->中断->Thread.join())

构造测试程序与数据(问题集中在如何验证测试数据? 如何提高测试程序的并发性? 如何跟踪线程)

测试内存泄露(可以使用 profile 工具)

性能测试

避免测试中的陷阱

GC，要求运行测试的时间足够长，以保证 JVM 有 GC 的发生

动态编译，同样要求运行测试的时间足够长，即 JVM 的预热，并且应该舍去第一运行的数据

关注 JVM 对代码的优化，主要集中在两个方面，一是测试程序对代码的覆盖率，另一个是避免 JVM 将一些测试基准当做 dead code 优化掉， 要求测试总在 -server 下运行

尽量的模仿实际情况

分析测试结果

CPU 是否被均匀的使用，如：一些 CPU 负载高，而另一些负载低，这说明大多数计算集中在某一(某些)线程(集合)中， 因此需要加强程序的并行化

CPU 是否被充分的使用，如：负载不够，I/O 限制，外部限制(如：数据库，web service等)，锁竞争，可以使用 profiler 来分析