如果你要考虑数据一致性或者线程安全的问题, 能承载 2 个线程就是解决了高并发的问题。

上周末跟老朋友聚会，谈到技术的时候，有一个共识，软件开发方面真正有价值的进步，应当是有利于用户、有利于项目管理、有利于解决领域问题，而不是有利于程序员。多年以来，主流语言和系统的很多改进，其目的都是为了让写程序的人感觉更爽，而与用户、管理和解决问题毫无关系。C++ 在这方面是带了一个很坏的头，又要追求强大的表达能力，又要追求不打折扣的效率，结果搞出一大堆诸如操作符重载，template meta-programming 之类的东西。老实讲，我也觉得：

在算法导论第一讲中(17:55 - 27:35)，作者做了一个比喻，性能是计算机编程中的货币，它是其他需求，比如安全，可维护性，可扩展性，良好的用户体验，这些需求的基础。

编程语言不过是一种内存游戏，定义的变量也好，对象也好，都只是在内存中的特定编码。其实根本就没什么语言，有的只是编译器。是编译器决定怎么解释某种关键字及某种语法。语言只是编译器和大家的约定，只要写入这样的代码，编译器便将其翻译成某种机器指令，翻译成什么样取决于编译器的行为，和语言无关。

与复杂度的斗争是软件开发的一个永恒的主题，我一次又一次地看到它反复出现，并且不断在各个层面上看到有关的争论：到底应该在函数和方法中进行多少注释？理想的抽象是怎样的？一个框架何时开始拥有了「过多的魔法」？ 什么时候组织中有太多语言？

UNIX 哲学基础

一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。

第九章 在一起更好还是分开更好？

软件设计中最基本的问题之一是：给定两个功能，它们应该在同一位置一起实现，还是应该分开实现？这个问题适用于系统中的所有级别，例如功能，方法，类和服务。例如，应该在提供面向流的文件 I/O 的类中包括缓冲，还是应该在单独的类中？HTTP 请求的解析应该完全在一种方法中实现，还是应该在多个方法（甚至多个类）之间划分？本章讨论做出这些决定时要考虑的因素。这些因素中的一些已经在前面的章节中进行了讨论，但是为了完整起见，这里将对其进行重新讨论。

第八章 降低复杂性

本章介绍了有关如何创建更深层类的另一种思考方式。假设您正在开发一个新模块，并且发现了一个不可避免的复杂性。哪个更好：应该让模块用户处理复杂性，还是应该在模块内部处理复杂性？如果复杂度与模块提供的功能有关，则第二个答案通常是正确的答案。大多数模块拥有的用户多于开发人员，因此开发人员遭受的苦难要大于用户。作为模块开发人员，您应该努力使模块用户的生活尽可能轻松，即使这对您来说意味着额外的工作。表达此想法的另一种方法是，模块具有简单的接口比简单的实现更为重要。

软件系统由层组成，其中较高的层使用较低层提供的功能。在设计良好的系统中，每一层都提供与其上，下两层不同的抽象。如果您通过调用方法遵循单个操作在层中上下移动，则每个方法调用的抽象都会改变。例如：

第六章 通用模块更深入

设计新模块时，您将面临的最普遍的决定之一就是是以通用还是专用方式实现它。有人可能会争辩说，您应该采用通用方法，在这种方法中，您将实现一种可用于解决广泛问题的机制，而不仅是当今重要的问题。在这种情况下，新机制可能会在将来发现意外用途，从而节省时间。通用方法似乎与第 3 章中讨论的投资思路一致，在这里您花了更多时间在前面，以节省以后的时间。

第五章 信息隐藏(和泄漏)

第四章认为模块应该很深。本章及随后的其他章节讨论了创建深层模块的技术。

第四章 模块应该是深的

管理软件复杂性最重要的技术之一就是设计系统，使开发者在任何时候都只需要面对整体复杂性的一小部分。这种方法被称为模块化设计，本章介绍其基本原则。

第三章 工作代码是不够的（战略与战术编程）

好的软件设计中最重要的元素之一是您在执行编程任务时所采用的思维方式。许多组织都鼓励采取战术思维方式，着眼于使功能尽快运行。但是，如果您想要一个好的设计，则必须采取更具战略性的方法，在此上花费时间来制作干净的设计并解决问题。本章讨论了从长远来看，为什么战略方法可以产生更好的设计，而实际上却比战术方法便宜。

第二章 复杂性的本质

这本书是关于如何设计软件系统以最小化其复杂性。第一步是了解敌人。究竟什么是“复杂性”？你如何判断系统是否过于复杂？是什么导致系统变得复杂？本章将在较高层次上解决这些问题。后续章节将向你展示如何从较低的层次上根据特定的结构特征来识别复杂性。

第一章 介绍

编写计算机软件是人类历史上最纯粹的创作活动之一。程序员不受诸如物理定律等实际限制的约束。我们可以用现实世界中永远不会存在的行为创建令人兴奋的虚拟世界。编程不需要很高的身体技能或协调能力，例如芭蕾或篮球。所有编程都需要具有创造力的头脑和组织思想的能力。如果您可以可视化系统，则可以在计算机程 序中实现它。

前言

80 多年来，人们一直在为电子计算机编写程序，但令人惊讶的是，关于如何设计这些程序或什么是好的程序应该是什么样子的讨论却很少。关于软件开发过程(如敏 捷开发)和开发工具(如调试器、版本控制系统和测试覆盖工具)，已经有了相当多的讨论。还广泛分析了编程技术，如面向对象编程和函数式编程，以及设计模式和算法。所有这些讨论都是有价值的，但是软件设计的核心问题在很大程度上仍然没有触及。David Parnas 的经典论文“关于将系统分解成模块的标准”发表于 1971 年，但是在随后的 45 年里，软件设计的技术水平并没有超过这篇论文。

编程语言越来越像思维的一部分。而编程这一过程就是用计算机作为媒介的一种表达。

你说的是 synchronization？这个有翻译的问题，当然也有你对 synchronization 概念理解的问题。很多人觉得 synchronization 指的就是互斥，操作层面这么说其实也没什么问题，毕竟，但凡被标记成 synchronized 的代码段，同一时间只有一个线程可以被准入。不过互斥并不是synchronization 的目的，只是达到 synchronization 的手段。

如果你要考虑数据一致性或者线程安全的问题, 能承载 2 个线程就是解决了高并发的问题。

以下列出一个学习提纲，主要针对的是有经验的人，初学者不合适。这个提纲只能用于一般的庸俗编程语言学习，目前在流行编程语言排行榜上排前20的基本上都是庸俗语言。如果你要学的是LISP之类非庸俗语言（这就是普通人驾驭不了的语言），或是某个软件中的二次开发语言，这里的建议未必合适。还是那句话，仅供参考。