回到云岛：所有 SaaS 用户都很高兴。因为他们能获得快速响应。因为这些用户惟一拥有的控制权就是对 访问应用程序的控制，他们不担心应用程序是否有多线程例程；也不担心在云中有多少核心用于并行加速多线 程的处理。问题应用程序被成功地从内部多线程 COBOL 遗留系统中迁移出来。
当然，有一天，SaaS 应用程序的速度会慢下来，而且越来越慢；直到用户无法忍受。他们这时才发现：
只有一个核心在正 常运行，其余核心都发生了故障。
SaaS 订阅仅限于两个核心，而不是所有四个核心。
SaaS 应用程序近 来升级出现了多线程缺陷。
故障转移计划失败。
同时，在岛上的功能部门，开发团队的人们聚在一 起思考各种解决方案，想让系统再次恢复运转。
本文帮助您探索多线程的性能问题，文中介绍了我第 一次遇到多线程时的遭遇（简言之，我会尽力将损失降至最低）。然后，本文查看了多线程控制模型云用户是 否在 Java 和 COBOL 中进行访问，并创建一个简洁的内置多线程支持。本文旨在向您展示供应商能够采取哪 些积极措施来停止伤害、解决问题、恢复系统和通知客户。
多线程性能
CPU 中的核心越多，在 执行程序代码指令时，多线程的表现就会越好，但是使用的核心数量不是决定多线程软件执行情况的惟一因素 。另一个因素是：对于某个任务或者进程，使用一个算法来完成完整的线程并行并不总是可行的。某些线程的 计算已经在之前的步骤中并行化了，可能得到一个连续的结果。
考虑到应用程序分散在模块中，每个 都被设计用于完成一个任务或者进程。在一个模块中，可以有 6 个几乎并行的单一线程。我们假设：
a 是线程 1，b 是线程 2，c 是线程 3，d 是线程 4，e 是线程 5，f 是线程 6
结果 r0、r1 和 r2 分别作为两个独立线程的组合并行线程进行计算，如下所示：
r0 = a + b
r1 = c + d
r2 = e + f
然而，添加所有三个并行线程结果（r0，r1 和 r2）会得到连续结果 g — 这并不是一 个新并行线程，如下所示：
g = r0 + r1 + r2
所有连续的部分都必须等待上一步中并行化的线 程发出准备好的信号。程序中的连续部分越多，从多核中获得的好处就越少。
其他影响多线程算法的 因素包括：
COBOL 的 THREAD 编译器选项限制。
Java 的多线程程序的限制。
将紧耦合 COBOL 程序中的缺陷分解到松耦合 SaaS 应用程序中。
云用户控制。
多线程阈值缺失。
我第一次遭遇线程
十几年前，在我第一次使用主机 COBOL 时，我考虑用非 COBOL 语言与其交互。我与一位教授进行了 有关的讨论，计划将此作为有关 COBOL 界面性能的论文主题。我分享了关于在程序代码中并行化线程来获得 子程序的想法。
为了弄清楚什么会影响性能，我根据 “Fortran 界面适用于 CODASYL 数据库任务组 规范”（参阅 参考资料）对迷你 COBOL/Fortran 界面进行了实验。Fortran 是当时的流行语言。那个时候， COBOL 还不像我们现在这样拥有 THREAD 选项。与如今我们见到的大型处理器相比，当时最大容量的处理器也 非常小。
在我的实验中，我发现部分 COBOL 数据类型没有 Fortran 等同物。当应用程序不再需要的 数据或者对象存在于磁盘上时，我根据需要调用子程序绕开了内存限制，然后在不需要数据或者对象时释放它 们并自动删除不再需要的数据。
每个子程序执行一个或者多个任务。在某些任务中，几个线程作为一 个并行线程进行计算（r0 = 线程 a + 线程 b）。所有连续部分都在等待上一步中的并行化线程发出准备好的 信号。等待很短暂。
如果当时我们有云，就可以使用运行在多核虚拟机上的平台即服务 (PaaS) 上的 多线程例程来开发一个 SaaS 应用程序。