前面文章中我们讲过为了充分利用现代多核计算机算力来提供应用程序的执行效率，一般情况下我们会采用多线程并发执行模型来编写。其中为了设计好此类程序我们首先需要识别出应用程序的分类是计算密集型还是I/O密集型应用程序。
如果是计算密集型应用程序，由于CPU只需要读取相关的数据进行计算即可，所以不适合设计成线程数多余计算机的内核数的模型，因为如此会造成线程上下文的频繁切换而影响性能，反而是根据计算机的内核数来启动线程数反而更能够提高该类应用程序在该机器集群上执行的效率。
如果是输入/输出密集型应用程序，由于输入/输出操作过程都是由操作系统调度输入/输出控制设备来完成的，CPU只负责相关事件相应，同时又由于输入输出控制设备读取外部数据的速度远低于CPU运行的速度，所以，此类程序执行必然面对这频繁的上下文切换，而不可能让一个线程阻塞等待回复。也就是说，I/O密集型应用应该采用设计多余内核数的线程，来让所有的CPU内核不间断的执行事件相应，最好是线程池里线程数远多于CPU核数，如此可以提供CPU的利用率。
从上面的例子说明在某些情况下，为应用程序添加新资源可以提高应用程序的整体性能。
其实我们在现实的开发过程中，在某些情况下，添加某些资源并不能带来相应的应用程序性能的提升。
那么是为什么呢？
我们知道在多核CPU上，多个线程可以并行执行，从而缩短执行时间，提高执行效率，但是并不是所有的应用程序都适合并行执行，而且大多数应用程序的流程都是串行和并行代码混合型的。对于需要串行执行的代码，是不可能由多个线程来同时执行的，也就是说，一个应用程序的效率提升一般都是在与能够并行执行部分决定的。
所以，为了能够计算我们的应用程序在添加更多资源时可以获得多少性能，我们需要确定程序中必须运行序列化/同步的部分，以及程序中可以并行运行的部分。
对于衡量一个应用程序的可并行程度方面，有一个著名的阿姆达尔定律：
它假设我们在一个可用CPU内核数为 N 的服务器上执行一个应用程序，应用程序的所有代码中只能顺序执行的代码行数所占代码总行数的比例为B，我们使用阿姆达尔定律可以估算出我们能够提高效率的上限。
如下是计算一个上限的加速我们的应用程序可以实现:
如果我们让n趋于无穷，也就是说CPU核数有无限个，(1-B)/n将无限的接近于0。
因此，此时我们可以忽略这一项，如此上面的公式就无限接近于1/B，我们知道这里的B是未执行优化处理的代码中不可并行的代码行数占比。
例如，如果B是0.5，也就是或我们的应用程序的代码行数中一半不能并行化，则0.5的倒数是2。
由此我们可以看出，即使我们向应用程序添加无限数量的处理器，我们也只能获得大约2个处理器内核的加速。
假设我们可以重写代码，让应用程序运行时需要同步执行的比例变为0.25。
那么由于0.25的倒数是4，这意味着我们已经构建了一个应用程序，它运行在大量处理器内核上的速度大约是只有一个处理器内核时的4倍。
反过来，我们也可以使用阿姆达尔定律来计算程序运行时中必须同步执行以达到给定加速的部分。
如果我们想实现大约100的加速，其倒数值是0.01，这意味着我们应该只设计大约1%的代码执行同步或者串行运行。
从上面对阿姆达尔定律的应用发现，我们可以得出这样的结论:
我们的程序通过使用增加额外处理能力所能获得的最大速度提升是受到程序在同步代码部分所花费的时间的倒数值的限制。
当然，在我们实际的操作中，这个分数通常是不容易准确计算的，更不能预估我们要开发的应用程序的业务大小，但这个定律给了我们一个提示就是我们在应用程序开发过程中必须非常仔细地考虑同步,并且尽量的必须让程序的序列化运算部分足够小，以此获得更好的性能提升。
我们知道了向应用程序添加更多的线程可以提高性能和响应能力。
但另一方面，添加更多线程也是有成本的，因为线程本身总会对性能产生一些影响。
第一个影响性能的地方是线程本身的创建，这个创建过程会消耗一些时间，因为JVM必须从底层操作系统获取线程的资源，并在调度程序中准备数据结构，并将决定接下来执行哪个线程。
如果我们使用跟处理器核数相同的线程数，那么每个线程都可以在自己的处理器上运行，并且不会经常被中断。
实际上，当应用程序运行时，操作系统本身当然可能也需要处理器来处理它自己的计算。
因此，在这种情况下，线程也会被中断，并且必须等待，直到操作系统允许它们再次运行。
当我们必须使用比CPU内核更多的线程时，情况会变得更糟。因为在这种情况下，调度程序需要不断的中断线程，以便让另一个线程执行它的代码。
这种执行使得操作系统需要保存正在运行的线程的当前状态，然后恢复计划运行的线程的状态。
除此之外，调度器本身还必须对其内部数据结构执行一些更新，让这些数据结构再次使用CPU算力。
总之，这意味着从一个线程到另一个线程的每个上下文切换都会消耗CPU的算力，因此与单线程解决方案相比，过多线程将会导致性能下降。
拥有多个线程的另一个代价是需要同步对共享数据结构的访问。
我们都知道在开发多线程并发访问共享资源的程序中，除了可以使用synchronized关键字之外，我们还可以使用volatile在多个线程之间共享数据。
如果多个线程竞争共享的数据，竞争就会产生。而我们的JVM就必须决定接下来执行哪个线程。
如果可以访问的线程不是当前线程的话，就会中断当前线程，引入要执行的线程，这一操作就会引入上下文切换的成本。
而当前线程就必须等待，直到它可以再次获得可以访问资源的锁。当然，JVM可以自行决定如何实现这种等待。
如果锁获取锁的预期时间很小时，采用自旋等待，也就是线程尝试一次又一次地获取锁，可能比挂起线程并让另一个线程占用CPU时所需的上下文切换更有效。
获取锁后，JVM需要将等待的线程切换会执行，这个过程需要另外一个上下文切换，这肯定会为锁争用增加额外的成本。
因此，由于存在锁的争用问题，减少必须的上下文切换次数是合理的。
本文我们简单介绍了在多线程并发编程设计时对于增加线程数给应用程序性能提升上限的估算，介绍了阿姆达尔定律的使用，即我们要关注的参数是可用的CPU内核数或者集群处理器数，代码中需要同步的代码行数比例估值，可用固定一个参数去看其它参数的变化对于性能提升带来的好处。