本文将解释为什么基于线程的编程并不是多核时代实现应用程序并行性的最佳方法。
摩尔定律（戈登·摩尔 1965 年预测，每个集成电路的元件数量每 18 到 24 个月就会翻一倍）仍然适用，它的适用性预计会持续到 2015-2020 年。2005 年之前，CPU 时钟速率也在同步提升，这本身已足以改进在这些 CPU 上执行的所有应用程序的性能。">应用程序开发社区只需对算法改进进行少量投资或者甚至无需投资，就可以坐享这一性能改进。
然而，从 2005 年开始，时钟速率的增长和晶体管数量的增长已不再同步。由于处理器材料的物理性质限制，时钟速率已停止增长（甚至下降），处理器制造商开始将更多执行单元（核心）封装到单个芯片（插槽）中。这一趋势（似乎能够在可预见的未来继续保持）已开始给应用程序开发和编程语言开发社区带来越来越大的压力，这大体表现在两个方面：
简单地升级到更强大的 CPU 无法再获得 2005 年之前单线程应用程序的性能增长速率。单线程应用程序的性能没有变化，无论 CPU 中有
多少个核心。也就是说，每核心吞吐量几乎是相同的，无论 CPU 拥有多少个核心（假设编译器、虚拟机或操作系统级别的自动并行化技术没有突破）。 升级到多核 CPU 仅能使系统上的增量负载受益，而不是让现有负载受益。
高效地利用可用 CPU 核心的惟一方法就是使用并行性。目前为止，主要由操作系统在进程级别上使用并行性来提供无缝的多任务、多处理体验。在应用程序开发方面，基于线程的并发编程是实现并行性的主导机制。
基于线程的并行性拥有以下优势：
它是一种受到广泛认可的编程模型。 应用程序开发社区对线程的创建、调度、执行和管理方式有
深入的了解。 开发人员已被培养为以序列方式思考算法开发。线程模型只是相同的方法在并行性方面的简单扩展。
但是，基于线程的应用程序并行性的问题大于优势。本文解释了显式的基于线程的应用程序并行性可能不是利用 CPU 核心的最佳方式和我们需要一种不同的编程模式的一些原因。
调用栈深度
调用栈是操作系统或虚拟机所维护的一种处理所有方法调用的内部结构。线程执行中的每次方法调用都会推进一个栈帧（由并行方法调用的详细信息组成，比如参数、返回地址和局部变量）。
图 1 显示了方法调用的内部原理：
图 1. 调用栈内部结构和增长
无论您如何将一个应用程序模块化为多个逻辑层（比如控制器层、外观层、组件层和数据访问对象 [DAO] 层），在运行时，线程是终极织入器 (weaver)，而且它只有一个堆栈。调用栈是在运行时处理源代码模块化方面的一项绝妙发明。但是，随着应用程序的复杂性和系统上的负载的增长，目前的调用栈结构模型限制了应用程序可伸缩性，而且它还存在与内存大小和对象可达性相关的内部问题。