资深工程师Judith M. Myerson结合自己的实际经历，讲述了内部部署的COBOL程序成功地转化为基于 Java 的软件即服务(SaaS)应用程序，开发人员应该小心提防多线程问题。

Judith提出了“多线程控制的模型云用户”概念：

多线程阈值的用途就是设置某个任务可以并行执行的线程数限制。在达到阈值时，完成自己工作的线程可以从其他线程队列中获取工作。

他分别比较了不同云平台上的控制粒度。

SaaS：用户拥有最少的控制，而供应商拥有最大控制。

最终用户控制：最终用户拥有的惟一控制就是从移动设备或虚拟台式计算机访问SaaS应用，无论它是私人的、企业的（中小型）还是政府机构的。SaaS应用程序示例包括船只到达和离开的时间表、客户关系管理、人力资源以及电子数据表。

SaaS供应商控制：至少，供应商可以通过限制授权用户的数量来管理访问控制，正如用户阈值策略中所述，授权用户能够同时访问多线程应用程序。供应商控制运行 SaaS 应用程序所需的核心、操作系统、服务器和网络基础架构。

多线程阈值控制：SaaS 最终用户没有多线程阈值的控制。供应商可能会将多线程的阈值限制为最大核心数，应用程序可用于并行处理线程。供应商设置的最大值取决于 SaaS 最终用户选择的订阅率。

PaaS：开发人员拥有更多的控制，而供应商只有较少的控制。

开发人员控制：开发人员控制并保护整个业务生命周期内的所有应用程序，这些应用程序是使用 PaaS创建的。开发人员将多线程阈值设置为在构建应用程序时可用于并行处理线程的核心数。开发人员可能会设置用户和虚拟桌面线程阈值的级别。

PaaS 供应商控制：供应商至少可以控制运行 SaaS 应用程序、开发新应用程序或测试在云中运行多线程所需的核心、操作系统、服务器和网络基础架构，以及应用程序的可扩展性。供应商可以设置资源、数据请求、社交媒体和负载平衡的阈值级别。

多线程阈值控制：开发人员可以根据应用程序中线程算法的复杂程度设置多线程的阈值。供应商将开发人员设置的阈值限制为开发人员执行线程时可能使用的最大核心数。

IaaS：基础架构或者网络专家拥有最多的控制。

网络专家控制：基础架构或者网络专家在虚拟级别控制核心、操作系统、网络设备和部署的多线程应用程序。基础架构专家能够扩大或者缩小虚拟服务器或者存储区域块，他们利用社交媒体工具与其他IaaS专家、PaaS专家和供应商进行通信。基础架构专家可能会设置用户、负载平衡和虚拟桌面阈值级别。

IaaS 供应商控制：供应商至少可以控制位于虚拟机底层的传统计算资源的基础架构、分配给基础架构或者网络专家的最多核心数，以及应用程序访问 IaaS 所需的应用程序。供应商可以设置用户、资源、数据请求、社交媒体和负载平衡的阈值级别。

多线程阈值控制：基础架构专家可能会设置多线程阈值。供应商可能会就各个虚拟服务器上的最大核心数与基础架构专家进行磋商。

接着，Judith谈到了自己对Java多线程使用的理解：

为了使用 Java 语言创建线程，可以实例化一个 Thread 类型（或者一个子类）对象，然后向它发送一个 start() 指令。线程将继续运行，直至 run() 返回主程序。这时线程将终止。大多数应用程序需要使用线程与其他进行通信，并同步其行为。要在 Java 程序中完成这项任务，至少需要使用锁。为了避免多次访问同一个线程，在使用资源前，线程可以获得和释放锁。试图获取某个正在使用中的锁的线程会陷入休眠状态，直到占用这个锁的线程将其释放。释放锁后，休眠线程就会移到准备运行的队列中。

锁的使用也会带来多线程的问题，包括死锁（两个或者多个相互竞争的操作等待其中一个完成工作，却导致无论哪个操作都无法完成。在计算机科学中，涉及两个相互竞争操作的死锁称为僵局 (deadly embrace)）。工作无法完成，因为很多线程都在等待永远无法释放的锁。局部引用无法在线程间传递，只在用来创造它们的线程中有效。如果传递局部引用，则无法在不再需要它们时将其释放。您应该经常将局部引用转化为全局引用，因为多线程有可能用到同一个引用。

另一个问题是，如果被调用的 COBOL 程序在执行中遇到 THREAD 编译器选项问题，那么使用设计良好的多线程程序调用 Java 程序将会失败。

对于多线程SaaS故障场景，Judith认为主要从以下4个方面来解决问题：

中止损害：为了中止损害，供应商应该提前计划，准备采用 SaaS 应用程序作为自动故障恢复的实例。根据 SaaS 订购者和供应商之间的协议，SLA 应该准备就绪。通知 SaaS 客户，在供应商解决问题时，应该同时在另一数据中心继续进行服务。请记住，将客户置于混乱的情况下往往会导致对您的不利。

解决问题：测试 SaaS 应用程序是否存在死锁和其他多线程问题。 设置各个语言界面（COBOL 和 Java）的多线程阈值。 安装多线程 SaaS 应用程序实例，允许将故障从一个数据中心转移到另一个数据中心。定期检查备用磁盘是否工作正常，并且没有错误。

恢复系统：下线数据中心已崩溃的系统。 将多线程 SaaS 应用程序迁移到恢复系统。然后测试恢复后的系统恢复力，确保将故障相对顺畅地转移到另一数据中心。在将它移动到生产环境中之前，应备份一个已恢复系统的副本。

通知客户：只要在故障数据中心恢复 SaaS 应用程序，供应商就应该通知客户恢复已经完成，SaaS 应用程序已经移动到生产环境，SLA 条款（无条件信用、退款和一个终止机会）正如与 SaaS 订阅者协商的那样在继续执行。