相比于编程领域的其他问题，多线程编程显得尤为困难。
– 多线程的环境使我们的程序非线性。没有人知道系统下一刻会执行哪一条语句。不幸的是，绝大多数程序（比如C++，Java）是线性地编写的：下一条语句总是在上一条执行完后执行。更严重的是，我们还在学习编程时就被灌输了，程序是线性执行的这一观点。因此，在多线程的编程范式上，绝大多程序员举步维艰。
– 多线性编程几乎是在多个方向上，爆炸般地撑大了程序的状态空间。我们很难在面对海量的程序状态的可能结果的情况下，仍然清晰地理解一个多线程程序，更毋论编写和测试程序。我们也很难去测试所有可能的状态，因为这些状态实在是太多了。
– 多线程编程使一个确定性的程序变为非确定性。这引入了更多测试上的问题。
– 糟糕的并发策略会显著地拖慢程序的性能，在一些并发策略的运行成本特别高昂的系统上（例如Windows），这个问题更为严重。
– 在多线程编程时，我们可用的debug工具非常少。如果找不到趁手的debug工具，真不如干脆当做自己没有任何调试工具。因此，忘掉调试器这回事吧。
– 很多语言，特别是C++，根本不支持多线程编程。Java在多线程上倒是有着出彩的表现，原因是Java实现了monitor机制。然而，这些机制并非一劳永逸的防弹衣，它们也并非在任何情形下都适用。
– 很多系统提供了内建的通过简陋的C调用实现的并发设计。然而，采用面向对象的并发实现会显得好的多，特别是在C++中，你可以控制构造/析构函数的加锁/解锁，从而达成预期的平衡。当前我成功地实现了这一点，并且我的C++环境有着一些非常棒的支持并发的对象。有趣的是，这些优秀的并发需要程序员自己来实现，而非囊括在语言特性中，我完全可以用功能等同的第三方代码来替换它们，从而测试我的多线程代码。
– 目前有许多著名的，广泛验证过的模式可用于处理并发问题，比如Exception Handling和Resumable Exception。报错往往相对地更多集中于程序代码中（debug是一个非常有趣的过程），所以异常检验尤为重要。异步故障引入了一些全新的故障类别，比如死锁，竞争条件，线程的报错处理和live lock。这些都错误通常都非常地模糊，你既不知道该再哪里处理这些错误，也不知道让谁来定义处理的代码。
原文地址
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
