并发范式
在合作中竞争，在竞争中合作 ——《竞合》
逗号好奇地问：“还有其他类型的编程范式吗？”
“不但有，而且有很多。”冒号喝了一口水，悠悠地说，“并发式编程就是其中之一。”
叹号有些惊讶：“并发式编程也算一种范式？它似乎更像是提供运行效率的一种手段。”
“大谬不然。”冒号摇摇头，“真正的并发式编程，绝不只是调用线程API或使用synchronized、lock之类的关键字那么简单。从宏观的架构设计，到微观的数据结构、流程控制乃至算法，相比通常的串行式编程都可能发生变化。随着硬件性能和用户需求的双重提升，并发式编程已成为不可回避的主题。毫不夸张地说，并发式编程是继OOP之后又一场思想和技术上的革命。只是相比OOP，尽管年龄相仿，但语言上不够支持，标准上不够统一，理论上不够完善，因而这场革命更具破坏性和建设性。现在我们来看一个例子，比较两种烧水泡茶的方案。”
说着冒号在黑板上写下——
方案一：洗茶杯；放茶叶；灌水壶；烧水；水开后泡茶。
方案二：灌水壶；在烧水的同时，洗茶杯；放茶叶；水开后泡茶。
引号见多识广：“我记得这好像是运筹学中的例子，显然方案二更佳。从编程的角度来看，方案一是串行式编程，方案二是并发式编程——烧水的线程与洗茶杯放茶叶的线程是同时进行的。”
“如果方案一也用并发式编程呢？”冒号追问。
引号一愣，随即道：“必须先洗茶杯后放茶叶，洗茶杯放茶叶的同时也没法烧水，至于泡茶，更得等水开之后了。”
“由此可见，单凭并发式编程并不能保证提高效率，还必须在程序设计上作改进。”冒号说道，“并发式编程以进程为导向（Process-Oriented），以资源共享与竞争为主线——与当今世界形势何其相似乃尔！这意味着程序设计将围绕进程的划分与调度、进程之间的通讯与同步等等来展开。合理的进程设计应该能做到——”
软件易于重用、维护、测试
公平有效地利用资源，优化程序性能如增大吞吐量、减少响应时间、提高效率等
保障进程安全，防止竞态条件（Race Condition）
保持进程活性，避免死锁、饥饿、活锁、资源枯竭等
减少锁开销、上下文切换等带来的性能损失
妥善处理多进程在算法、调试等方面带来的复杂性
叹号蹙眉：“并发式编程好是好，就是太复杂。”
冒号淡淡地说：“天下没有免费的午餐。并发式编程当然不容易，但也并非难以掌握。最重要的是，作为一个程序员，你不得不面对它。即使你不直接用并发式编程，你依赖的代码和依赖你的代码也可能用到；即使现在没有用并发式，将来也可能用到。如果采取避而不理的鸵鸟政策，早晚会被人点中你的死穴。”
句号谈及他的感受：“相比OOP在语言上得到的支持，并发式的支持力度好像很不够。”
冒号点头称是：“这是由并发式的复杂性和成熟度决定的。主流语言中Java和C#对并发式编程在语法上有一定的支持，而C与C++除了关键字volatile外，主要靠library支持。专门为并发式而设计的语言大多仅限于学术研究而非商业应用，Erlang语言是少数的例外。”
问号提了一个听似奇怪的问题：“并发式与前面提到的对象式有无共通之处？”
“并发式与对象式虽是互相正交的两种范式，倒真有些相通呢。”冒号回答，“它们均与三大基本范式正交，并且越来越广泛地向它们渗透着；均为传统编程的一种推广——并发式进程的个数为一时即为传统的串行式编程，对象的方法个数为为零即为传统的数据结构；均将整个程序系统分解为若干独立的子系统，不同的是一个以任务为单位，一个以对象为单位；子系统之间均能交流与合作，不同的是一个以竞争为主题，一个以服务为主题。如果将程序系统视作公司，那么并发式系统是产品型公司，每个进程是一名工人，其职责是执行单一任务；对象式系统是服务型公司，每个对象是一名服务员，其职责是提供系列服务。由此可见，一名优秀的程序设计师也应该是一名优秀的管理者。”
句号提出：“迄今为止我们谈到了五种范式，能否对它们简单概括一下？”
少顷，黑板上出现几行排比句——
过程式：以过程为模块的君主体系，模块之间互相授命与听命
函数式：以函数为模块的数学体系，模块之间互相替换与合成
逻辑式：以断言为模块的逻辑体系，模块之间互相归纳与演绎
对象式：以对象为模块的民主体系，模块之间互相交流与服务
并发式：以进程为模块的生产体系，模块之间互相竞争与合作
“并发式编程要求我们摆脱以往习惯的按部就班的思维方式，对编程提出了更高的挑战。程序世界与现实世界一样，呈百舸争流、千帆竞发之势，不进则退啊！”言讫，冒号宣布，“第二堂课到此为止，欢迎下次光临。”
幸福不是因为你拥有得多，而是由于你计较得少。
