diff --git a/README.md b/README.md index e6c333a9..9e9e83bd 100644 --- a/README.md +++ b/README.md @@ -3,8 +3,7 @@ ## 书籍简介 - 本书原作者为 [美] Bruce Eckel，即《Java 编程思想》的作者。 -- 本书是事实上的 《Java 编程思想》第五版。 -- 《Java 编程思想》第四版基于 JAVA **5** 版本；《On Java 8》 基于 JAVA **8** 版本。 + ## 传送门 @@ -99,7 +98,7 @@ 1. 本书排版布局和翻译风格上参考**阮一峰**老师的 [中文技术文档的写作规范](https://github.com/ruanyf/document-style-guide) 2. 采用第一人称叙述。 3. 由于中英行文差异，完全的逐字逐句翻译会很冗余啰嗦。所以本人在翻译过程中，去除了部分主题无关内容、重复描写。 -4. 译者在翻译中同时参考了谷歌、百度、有道翻译的译文以及《Java 编程思想》第四版中文版的部分内容（对其翻译死板，生造名词，语言精炼度差问题进行规避和改正）。最后结合译者自己的理解进行本地化，尽量做到专业和言简意赅，方便大家更好的理解学习。 +4. 译者在翻译中同时参考了谷歌、百度、有道翻译的译文。最后结合译者自己的理解进行本地化，尽量做到专业和言简意赅，方便大家更好的理解学习。 5. 由于译者个人能力、时间有限，如有翻译错误和笔误的地方，还请大家批评指正！ ## 如何参与 diff --git a/book.json b/book.json index dd18be46..36f77afe 100644 --- a/book.json +++ b/book.json @@ -1,7 +1,7 @@ { "title": "《On Java 8》中文版", "author": "LingCoder", - "description": "根据 Bruce Eckel 大神的新书 On Java 8 翻译，可以说是事实上的 Thinking in Java 5th", + "description": "", "language": "zh-hans", "gitbook": "3.2.3", "styles": { diff --git a/docs/README.md b/docs/README.md index fca2f067..d51ce131 100644 --- a/docs/README.md +++ b/docs/README.md @@ -9,8 +9,6 @@ ## 书籍简介 * 本书原作者为 [美] Bruce Eckel，即《Java 编程思想》的作者。 -* 本书是事实上的 《Java 编程思想》第五版。 -* 《Java 编程思想》第四版基于 JAVA **5** 版本；《On Java 8》 基于 JAVA **8** 版本。 ## 翻译说明 @@ -18,7 +16,7 @@ 1. 本书排版布局和翻译风格上参考了**阮一峰**老师的 [中文技术文档的写作规范](https://github.com/ruanyf/document-style-guide) 2. 采用第一人称叙述。 3. 由于中英行文差异，完全的逐字逐句翻译会很冗余啰嗦。所以本人在翻译过程中，去除了部分主题无关内容、重复描写。 -4. 译者在翻译中同时参考了谷歌、百度、有道翻译的译文以及《Java编程思想》第四版中文版的部分内容（对其翻译死板，生造名词，语言精炼度差问题进行规避和改正）。最后结合译者自己的理解进行本地化，尽量做到专业和言简意赅，方便大家更好的理解学习。 +4. 译者在翻译中同时参考了谷歌、百度、有道翻译的译文。最后结合译者自己的理解进行本地化，尽量做到专业和言简意赅，方便大家更好的理解学习。 5. 由于译者个人能力、时间有限，如有翻译错误和笔误的地方，还请大家批评指正！ ## 如何参与 diff --git a/docs/_coverpage.md b/docs/_coverpage.md index 09ca8f43..68c3bf2f 100644 --- a/docs/_coverpage.md +++ b/docs/_coverpage.md @@ -2,7 +2,7 @@ # On Java 8 -- 《On Java 8》中文版，是事实上的《Java 编程思想》第5版。 +- 《On Java 8》中文版。 [![stars](https://badgen.net/github/stars/lingcoder/OnJava8?icon=github&color=4ab8a1)](https://github.com/lingcoder/OnJava8) [![forks](https://badgen.net/github/forks/lingcoder/OnJava8?icon=github&color=4ab8a1)](https://github.com/lingcoder/OnJava8) diff --git a/docs/book/00-Introduction.md b/docs/book/00-Introduction.md index bcd233c0..a9ec9f27 100644 --- a/docs/book/00-Introduction.md +++ b/docs/book/00-Introduction.md @@ -1,7 +1,7 @@ # 简介 -> “我的语言极限，即是我的世界的极限。” ——路德维希·维特根斯坦（*Wittgenstein*） +> “语言观决定世界观。” ——路德维希·维特根斯坦（*Wittgenstein*） 这句话无论对于自然语言还是编程语言来说都是一样的。你所使用的编程语言会将你的思维模式固化并逐渐远离其他语言，而且往往发生在潜移默化中。Java 作为一门傲娇的语言尤其如此。 diff --git a/docs/book/02-Installing-Java-and-the-Book-Examples.md b/docs/book/02-Installing-Java-and-the-Book-Examples.md index 86f76082..e3350b02 100644 --- a/docs/book/02-Installing-Java-and-the-Book-Examples.md +++ b/docs/book/02-Installing-Java-and-the-Book-Examples.md @@ -111,7 +111,7 @@ Mac 系统自带的 Java 版本太老，为了确保本书的代码示例能被 2. 在命令行下执行下面的命令来安装 Java。 ```bash - brew cask install java + brew install java --cask ``` 当以上安装都完成后，如果你有需要，可以使用游客账户来运行本书中的代码示例。 diff --git a/docs/book/04-Operators.md b/docs/book/04-Operators.md index 40ae0a9f..14f8fcf7 100644 --- a/docs/book/04-Operators.md +++ b/docs/book/04-Operators.md @@ -1436,7 +1436,7 @@ public class AllOps { ```java // operators/Overflow.java -// 厉害了！内存溢出 +// 厉害了！数据溢出了！ public class Overflow { public static void main(String[] args) { int big = Integer.MAX_VALUE; diff --git a/docs/book/06-Housekeeping.md b/docs/book/06-Housekeeping.md index 0248808c..db3510bf 100644 --- a/docs/book/06-Housekeeping.md +++ b/docs/book/06-Housekeeping.md @@ -1130,7 +1130,7 @@ public class ExplicitStatic { 输出： ``` -Inside main +Inside main() Cup(1) Cup(2) f(99) @@ -1182,7 +1182,7 @@ public class Mugs { 输出： ``` -Inside main +Inside main() Mug(1) Mug(2) mug1 & mug2 initialized diff --git a/docs/book/07-Implementation-Hiding.md b/docs/book/07-Implementation-Hiding.md index 874ba9ce..946b77f7 100644 --- a/docs/book/07-Implementation-Hiding.md +++ b/docs/book/07-Implementation-Hiding.md @@ -61,7 +61,7 @@ import java.util.* ### 代码组织 -当编译一个 **.java** 文件时，**.java** 文件的每个类都会有一个输出文件。每个输出的文件名和 **.java** 文件中每个类的类名相同，只是后缀名是 **.class**。因此，在编译少量的 **.java** 文件后，会得到大量的 **.class** 文件。如果你使用过编译型语言，那么你可能习惯编译后产生一个中间文件（通常称为“obj”文件），然后与使用链接器（创建可执行文件）或类库生成器（创建类库）产生的其他同类文件打包到一起的情况。这不是 Java 工作的方式。在 Java 中，可运行程序是一组 **.class** 文件，它们可以打包压缩成一个 Java 文档文件（JAR，使用 **jar** 文档生成器）。Java 解释器负责查找、加载和解释这些文件。 +当编译一个 **.java** 文件时， **.java** 文件的每个类都会有一个输出文件。每个输出的文件名和 **.java** 文件中每个类的类名相同，只是后缀名是 **.class**。因此，在编译少量的 **.java** 文件后，会得到大量的 **.class** 文件。如果你使用过编译型语言，那么你可能习惯编译后产生一个中间文件（通常称为“obj”文件），然后与使用链接器（创建可执行文件）或类库生成器（创建类库）产生的其他同类文件打包到一起的情况。这不是 Java 工作的方式。在 Java 中，可运行程序是一组 **.class** 文件，它们可以打包压缩成一个 Java 文档文件（JAR，使用 **jar** 文档生成器）。Java 解释器负责查找、加载和解释这些文件。 类库是一组类文件。每个源文件通常都含有一个 **public** 类和任意数量的非 **public** 类，因此每个文件都有一个 **public** 组件。如果把这些组件集中在一起，就需要使用关键字 **package**。 @@ -327,7 +327,7 @@ public class Cookie { } ``` -记住，**Cookie.java** 文件产生的类文件必须位于名为 **dessert** 的子目录中，该子目录在 **hiding** （表明本书的"封装"章节）下，它必须在 CLASSPATH 的几个目录之下。不要错误地认为 Java 总是会将当前目录视作查找行为的起点之一。如果你的 CLASSPATH 中没有 **.**，Java 就不会查找当前目录。 +记住，**Cookie.java** 文件产生的类文件必须位于名为 **dessert** 的子目录中，该子目录在 **hiding** （表明本书的"封装"章节）下，它必须在 CLASSPATH 的几个目录之下。不要错误地认为 Java 总是会将当前目录视作查找行为的起点之一。如果你的 CLASSPATH 中没有 **.** ，Java 就不会查找当前目录。 现在，使用 **Cookie** 创建一个程序： ```java @@ -384,7 +384,7 @@ class Pie { } ``` -最初看上去这两个文件毫不相关，但在 **Cake** 中可以创建一个 **Pie** 对象并调用它的 `f()` 方法。（注意，你的 CLASSPATH 中一定得有 **.**，这样文件才能编译）通常会认为 **Pie** 和 `f()` 具有包访问权限，因此不能被 **Cake** 访问。它们的确具有包访问权限，这是部分正确。**Cake.java** 可以访问它们是因为它们在相同的目录中且没有给自己设定明确的包名。Java 把这样的文件看作是隶属于该目录的默认包中，因此它们为该目录中所有的其他文件都提供了包访问权限。 +最初看上去这两个文件毫不相关，但在 **Cake** 中可以创建一个 **Pie** 对象并调用它的 `f()` 方法。（注意，你的 CLASSPATH 中一定得有 **.** ，这样文件才能编译）通常会认为 **Pie** 和 `f()` 具有包访问权限，因此不能被 **Cake** 访问。它们的确具有包访问权限，这是部分正确。**Cake.java** 可以访问它们是因为它们在相同的目录中且没有给自己设定明确的包名。Java 把这样的文件看作是隶属于该目录的默认包中，因此它们为该目录中所有的其他文件都提供了包访问权限。 ### private: 你无法访问 diff --git a/docs/book/20-Generics.md b/docs/book/20-Generics.md index 72263fcc..d93b82ed 100644 --- a/docs/book/20-Generics.md +++ b/docs/book/20-Generics.md @@ -2666,7 +2666,7 @@ public class GenericsAndCovariance { } ``` -**flist** 的类型现在是 `List`，你可以读作“一个具有任何从 **Fruit** 继承的类型的列表”。然而，这实际上并不意味着这个 **List** 将持有任何类型的 **Fruit**。通配符引用的是明确的类型，因此它意味着“某种 **flist** 引用没有指定的具体类型”。因此这个被赋值的 **List** 必须持有诸如 **Fruit** 或 **Apple** 这样的指定类型，但是为了向上转型为 **Fruit**，这个类型是什么没人在意。 +**flist** 的类型现在是 `List`，你可以读作“一个具有任何从 **Fruit** 继承的类型的列表”。然而，这实际上并不意味着这个 **List** 将持有任何类型的 **Fruit**。通配符引用的是明确的类型，因此它意味着“某种 **flist** 引用没有指定的具体类型”。因此这个被赋值的 **List** 必须持有诸如 **Fruit** 或 **Apple** 这样的指定类型，但是为了向上转型为 **flist**，这个类型是什么没人在意。 **List** 必须持有一种具体的 **Fruit** 或 **Fruit** 的子类型，但是如果你不关心具体的类型是什么，那么你能对这样的 **List** 做什么呢？如果不知道 **List** 中持有的对象是什么类型，你怎能保证安全地向其中添加对象呢？就像在 **CovariantArrays.java** 中向上转型一样，你不能，除非编译器而不是运行时系统可以阻止这种操作的发生。你很快就会发现这个问题。 diff --git a/docs/book/24-Concurrent-Programming.md b/docs/book/24-Concurrent-Programming.md index 201b9a3d..67de4a97 100755 --- a/docs/book/24-Concurrent-Programming.md +++ b/docs/book/24-Concurrent-Programming.md @@ -12,39 +12,32 @@ > > 猫咪：“你一定是疯了，否则你就不会来这儿” ——爱丽丝梦游仙境 第 6 章。 +在本章之前，我们惯用一种简单顺序的叙事方式来编程，有点类似文学中的意识流：第一件事发生了，然后是第二件，第三件……总之，我们完全掌握着事情发生的进展和顺序。如果我们将一个值设置为 5，再看时它已变成 47 的话，这就令人匪夷所思了。 -在本章之前，我们惯用一种简单顺序的叙事方式来编程，有点类似文学中的意识流：第一件事发生了，然后是第二件，第三件……总之，我们完全掌握着事情发生的进展和顺序。如果将值设置为 5，再看时它已变成 47 的话，结果就很匪夷所思了。 +现在，我们来到了陌生的并发世界，在这里这样的结果一点都不奇怪。你原来相信的一切都不再可靠。原有的规则可能生效也可能失效。更可能的是原有的规则只会在某些情况下生效。我们只有完全了解这些情况，才能决定我们处理事情的方式。 -现在，我们来到了陌生的并发世界。这样的结果一点都不奇怪，因为你原来信赖的一切都不再可靠。它可能有效，也可能无效。更可能得是，它在某些情况下会起作用，而在另一些情况下则不会。只有了解了这些情况，我们才能正确地行事。 - -作为类比，我们正常生活是发生在经典牛顿力学中的。物体具有质量：会坠落并转移动量。电线有电阻，光直线传播。假如我们进入极小、极热、极冷、或是极大的世界（我们不能生存），这些现象就会发生变化。我们无法判断某物体是粒子还是波，光是否受到重力影响，一些物质还会变为超导体。 +比如，我们正常的生活的世界是遵循经典牛顿力学的。物体具有质量：会坠落并且转移动能。电线有电阻，光沿直线传播。假如我们进入到极小、极大、极冷或者极热（那些我们无法生存的世界），这些现象就会发生改变。我们无法判断某物体是粒子还是波，光是否受到重力影响，一些物质还会变为超导体。 假设我们处在多条故事线并行的间谍小说里，非单一意识流地叙事：第一个间谍在岩石底留下了微缩胶片。当第二个间谍来取时，胶片可能已被第三个间谍拿走。小说并没有交代此处的细节。所以直到故事结尾，我们都没搞清楚到底发生了什么。 -构建并发程序好比玩[搭积木 ](https://en.wikipedia.org/wiki/Jenga) 游戏。每拉出一块放在塔顶时都有崩塌的可能。每个积木塔和应用程序都是独一无二的，有着自己的作用。你在某个系统构建中学到的知识并不一定适用于下一个系统。 +构建并发程序好比玩[搭积木](https://en.wikipedia.org/wiki/Jenga)游戏。每拉出一块放在塔顶时都有崩塌的可能。每个积木塔和应用程序都是独一无二的，有着自己的作用。你在某个系统构建中学到的知识并不一定适用于下一个系统。 本章是对并发概念最基本的介绍。虽然我们用到了现代的 Java 8 工具来演示原理，但还远未及全面论述并发。我的目标是为你提供足够的基础知识，使你能够把握问题的复杂性和危险性，从而安全地渡过这片鲨鱼肆虐的困难水域。 -更多繁琐和底层的细节，请参阅附录：[并发底层原理 ](./Appendix-Low-Level-Concurrency.md)。要进一步深入这个领域，你还必须阅读 *Brian Goetz* 等人的 《Java Concurrency in Practice》。在撰写本文时，该书已有十多年的历史了，但它仍包含我们必须要了解和明白的知识要点。理想情况下，本章和上述附录是阅读该书的良好前提。另外，*Bill Venner* 的 《Inside the Java Virtual Machine》也很值得一看。它详细描述了 JVM 的内部工作方式，包括线程。 - - - +更多繁琐和底层的细节，请参阅附录：[并发底层原理](https://github.com/LingCoder/OnJava8/blob/master/docs/book/Appendix-Low-Level-Concurrency.md)。要进一步深入这个领域，你还必须阅读 *Brian Goetz* 等人的 《Java Concurrency in Practice》。在撰写本文时，该书已有十多年的历史了，但它仍包含我们必须要了解和明白的知识要点。理想情况下，本章和上述附录是阅读该书的良好前提。另外，*Bill Venner* 的 《Inside the Java Virtual Machine》也很值得一看。它详细描述了包括线程在内的 JVM 的内部工作方式。 ## 术语问题 -术语“并发”，“并行”，“多任务”，“多处理”，“多线程”，分布式系统（可能还有其他）在整个编程文献中都以多种相互冲突的方式使用，并且经常被混为一谈。 -*Brian Goetz* 在他 2016 年《从并发到并行》的演讲中指出了这一点，之后提出了合理的二分法： +术语“并发”，“并行”，“多任务”，“多处理”，“多线程”，分布式系统（可能还有其他）在整个编程文献中都以多种相互冲突的方式使用，并且经常被混为一谈。 *Brian Goetz* 在他 2016 年《从并发到并行》的演讲中指出了这一点，之后提出了合理的区分： - 并发是关于正确有效地控制对共享资源的访问。 - - 并行是使用额外的资源来更快地产生结果。 这些定义很好，但是我们已有几十年混乱使用和抗拒解决此问题的历史了。一般来说，当人们使用“并发”这个词时，他们的意思是“所有的一切”。事实上，我自己也经常陷入这样的想法。在大多数书籍中，包括 *Brian Goetz* 的 《Java Concurrency in Practice》，都在标题中使用这个词。 -“并发”通常表示：不止一个任务正在执行。而“并行”几乎总是代表：不止一个任务同时执行。现在你能看到问题所在了吗？“并行”也有不止一个任务正在执行的语义在里面。区别就在于细节：究竟是怎么“执行”的。此外，还有一些场景重叠：为并行编写的程序有时在单处理器上运行，而一些并发编程系统可以利用多处理器。 +“并发”通常表示：”不止一个任务正在执行“。而“并行”几乎总是代表：”不止一个任务同时执行“。现在我们能立即看出这些定义中的问题所在：“并行”也有不止一个任务正在执行的语义在里面。区别就在于细节：究竟是怎么“执行”的。此外还有一些重叠：为并行编写的程序依旧可以在单处理器上运行，而并发编写的系统也可以利用多个处理器。 -还有另一种方法，在减速发生的地方写下定义（原文 Here’s another approach, writing the definitions around where the -slowdown occurs）： +还有另一种方式，围绕”缓慢“出现的情况写下定义： **并发** @@ -60,37 +53,37 @@ slowdown occurs）： 我们甚至可以尝试以更细的粒度去进行定义（然而这并不是标准化的术语）： -- **纯并发**：仍然在单个 CPU 上运行任务。纯并发系统比顺序系统更快地产生结果，但是它的运行速度不会因为处理器的增加而变得更快。 -- **并发-并行**：使用并发技术，结果程序可以利用更多处理器更快地产生结果。 -- **并行-并发**：使用并行编程技术编写，如果只有一个处理器，结果程序仍然可以运行（Java 8 **Streams** 就是一个很好的例子）。 -- **纯并行**：除非有多个处理器，否则不会运行。 +- **纯并发**：仍然在单个 CPU 上运行任务。纯并发系统比时序系统更快地产生结果，但是它的运行速度不会因为处理器的增加而变得更快。 + +- **并发-并行**：使用并发技术，结果程序可以利用多处理器更快地产生结果。 +- **并行-并发**：使用并行编程技术编写，即使只有一个处理器，结果程序仍然可以运行（Java 8 **Streams** 就是一个很好的例子）。 +- **纯并行**：只有多个处理器的情况下才能运行。 + +在某些情况下，这是一个有效的分类法。 -在某些情况下，这可能是一个有用的分类法。 +支持并发性的语言和库似乎是[抽象泄露（Leaky Abstraction](https://en.wikipedia.org/wiki/Leaky_abstraction)一词的完美候选。抽象的目标是“抽象”掉那些对手头的想法不重要的部分，以屏蔽不必要的细节所带来的影响。如果抽象发生泄露，那么即使费很大功夫去隐藏它们，这些细枝末节也总会不断凸显出自己是重要的。 -支持并发性的语言和库似乎是[抽象泄露（Leaky Abstraction）](https://en.wikipedia.org/wiki/Leaky_abstraction) 一词的完美候选。抽象的目标是“抽象出”那些对于手头想法不重要的东西，以屏蔽不必要的细节。如果抽象是有漏洞的，那些碎片和细节就会不断重新声明自己是重要的，无论你废了多少功夫来隐藏它们。 +于是我开始怀疑是否真的有高度地抽象。因为当编写这类程序时，底层的系统、工具，甚至是关于 CPU 缓存如何工作的细节，都永远不会被屏蔽。最后，即使你已非常谨慎，你开发的程序也不一定在所有情况下运行正常。有时是因为两台机器的配置不同，有时是程序的预计负载不同。这不是 Java 特有的 - 这是并发和并行编程的本质。 -我开始怀疑是否真的有高度抽象。因为当编写这类程序时，底层的系统、工具，甚至是关于 CPU 缓存如何工作的细节，都永远不会被屏蔽。最后，如果你非常小心，你创作的东西在特定的情况下工作，但在其他情况下不工作。有时是两台机器的配置方式不同，有时是程序的估计负载不同。这不是 Java 特有的 - 这是并发和并行编程的本质。 +你可能会认为[纯函数式](https://en.wikipedia.org/wiki/Purely_functional)语言没有这些限制。实际上，纯函数式语言的确解决了大量并发问题。如果你正在解决一个困难的并发问题，可以考虑用纯函数语言编写这个部分。但是，如果你编写一个使用队列的系统，例如，如果该系统没有被合理地调优，并且输入速率也没有被正确地估计或限制（在不同的情况下，限制意味着具有不同的影响的不同东西），该队列要么被填满并阻塞，要么溢出。最后，你必须了解所有可能会破坏你的系统的细节和问题。这是一种非常不同的编程方式。 -你可能会认为[纯函数式 ](https://en.wikipedia.org/wiki/Purely_functional) 语言没有这些限制。实际上，纯函数式语言解决了大量并发问题，所以如果你正在解决一个困难的并发问题，你可以考虑用纯函数语言编写这个部分。但最终，如果你编写一个使用队列的系统，例如，如果该系统没有被正确地调整，并且输入速率也没有被正确地估计或限制（在不同的情况下，限制意味着具有不同的影响的不同东西），该队列要么被填满并阻塞，要么溢出。最后，你必须了解所有细节，任何问题都可能会破坏你的系统。这是一种非常不同的编程方式。 +## 并发的新定义 - -### 并发的新定义 +几十年来，我一直在努力解决各种形式的并发问题，其中一个最大的挑战是简洁的定义它。在撰写本章的过程中，我终于有了这样的洞察力，我将其定义为： -几十年来，我一直在努力解决各种形式的并发问题，其中一个最大的挑战一直是简单地定义它。在撰写本章的过程中，我终于有了这样的洞察力，我认为可以定义它： ->** 并发性是一系列性能技术，专注于减少等待** +> 并发性是一系列专注于减少等待的性能技术 这实际上是一个相当复杂的表述，所以我将其分解： -- 这是一个集合：包含许多不同的方法来解决这个问题。这是使定义并发性如此具有挑战性的问题之一，因为技术差异很大。 -- 这些是性能技术：就是这样。并发的关键点在于让你的程序运行得更快。在 Java 中，并发是非常棘手和困难的，所以绝对不要使用它，除非你有一个重大的性能问题 - 即使这样，使用最简单的方法产生你需要的性能，因为并发很快变得无法管理。 -- “减少等待”部分很重要而且微妙。无论（例如）你运行多少个处理器，你只能在等待发生时产生效益。如果你发起 I/O 请求并立即获得结果，没有延迟，因此无需改进。如果你在多个处理器上运行多个任务，并且每个处理器都以满容量运行，并且没有任务需要等待其他任务，那么尝试提高吞吐量是没有意义的。并发的唯一机会是如果程序的某些部分被迫等待。等待可以以多种形式出现 - 这解释了为什么存在如此不同的并发方法。 +- 这是一个集合：包含许多不同的方法来解决这个问题。因为技术差异很大，这是使定义并发性如此具有挑战性的问题之一。 +- 这些是性能技术：就是这样。并发的关键点在于让你的程序运行得更快。在 Java 中，并发是非常棘手和困难的，所以绝对不要使用它，除非你有一个重大的性能问题 - 即使这样，使用最简单的方法产生你需要的性能，因为并发很快变得难以管理。 +- “减少等待”部分很重要而且微妙。无论（例如）你的程序运行在多少个处理器上，你只能在等待发生时产生效益。如果你发起 I/O 请求并立即获得结果，没有延迟，因此无需改进。如果你在多个处理器上运行多个任务，并且每个处理器都以满容量运行，并且没有任务需要等待其他任务，那么尝试提高吞吐量是没有意义的。并发的唯一机会是程序的某些部分被迫等待。等待会以多种形式出现 - 这解释了为什么存在多种不同的并发方法。 值得强调的是，这个定义的有效性取决于“等待”这个词。如果没有什么可以等待，那就没有机会去加速。如果有什么东西在等待，那么就会有很多方法可以加快速度，这取决于多种因素，包括系统运行的配置，你要解决的问题类型以及其他许多问题。 - ## 并发的超能力 -想象一下，你置身于一部科幻电影。你必须在一栋大楼中找到一个东西，它被小心而巧妙地隐藏在大楼一千万个房间中的一间。你进入大楼，沿着走廊走下去。走廊是分开的。 +想象一下，你置身于一部科幻电影。你必须在一栋大楼中找到一个东西，它被小心而巧妙地隐藏在大楼千万个房间中的一间。你进入大楼，沿着走廊走下去。走廊是分开的。 一个人完成这项任务要花上一百辈子的时间。 @@ -100,31 +93,31 @@ slowdown occurs）： 一旦克隆体进入房间，它必须搜索房间的每个角落。这时它切换到了第二种超能力。它分裂成了一百万个纳米机器人，每个机器人都会飞到或爬到房间里一些看不见的地方。你不需要了解这种功能 - 一旦你开启它就会自动工作。在他们自己的控制下，纳米机器人开始行动，搜索房间然后回来重新组装成你，突然间，不知怎么的，你就知道这间房间里有没有那个东西。 -我很想说，“并发就是刚才描述的置身于科幻电影中的超能力“就像你自己可以一分为二然后解决更多的问题一样简单。但是问题在于，我们来描述这种现象的任何模型最终都是泄漏抽象的（leaky abstraction)。 +我很想说，“并发就是刚才描述的置身于科幻电影中的超能力“。就像你自己可以一分为二然后解决更多的问题一样简单。但是问题在于，我们来描述这种现象的任何模型最终都是抽象泄露的（leaky abstraction)。 -以下是其中一个漏洞：在理想的世界中，每次克隆自己时，还需要复制一个物理处理器来运行该克隆。这当然是不现实的——实际上，你的机器上一般只有 4 个或 8 个处理器核心（编写本文时的典型情况）。你也可能更多，但仍有很多情况下只有一个单核处理器。在关于抽象的讨论中，分配物理处理器核心这本身就是抽象的泄露，甚至也可以支配你的决策。 +以下是其中一个泄露：在理想的世界中，每次克隆自己时，也会复制一个物理处理器来运行克隆搜索者。这当然是不现实的——实际上，你的机器上一般只有 4 个或 8 个处理器核心（编写本文时的典型情况）。或许你拥有更多的处理器，但仍有很多情况下只有一个单核处理器。在关于抽象的讨论中，分配物理处理器核心这本身就是抽象的泄露，甚至也可以支配你的决策。 让我们在科幻电影中改变一些东西。现在当每个克隆搜索者最终到达一扇门时，他们必须敲门并等到有人开门。如果每个搜索者都有一个处理器核心，这没有问题——只是空闲等待直到有人开门。但是如果我们只有 8 个处理器核心却有几千个搜索者，我们不希望处理器仅仅因为某个搜索者恰好在等待回答中被锁住而闲置下来。相反，我们希望将处理器应用于可以真正执行工作的搜索者身上，因此需要将处理器从一个任务切换到另一个任务的机制。 -许多模型能够有效地隐藏处理器的数量，允许你假装有很多个处理器。但在某些情况下，这种方法会失效，这时你必须知道处理器核心的真实数量，以便处理这个问题。 +许多模型能够有效地隐藏处理器的数量，允许你假装有很多个处理器。但在某些情况下，当你必须明确知道处理器数量以便于工作的时候，这些模型就会失效。 -最大的影响之一取决于您是使用单核处理器还是多核处理器。如果你只有单核处理器，那么任务切换的成本也由该核心承担，将并发技术应用于你的系统会使它运行得更慢。 +最大的影响之一取决于是使用单核处理器还是多核处理器。如果你只有单核处理器，那么任务切换的成本也由该核心承担，将并发技术应用于你的系统会使它运行得更慢。 这可能会让你以为，在单核处理器的情况下，编写并发代码是没有意义的。然而，有些情况下，并发模型会产生更简单的代码，光是为了这个目的就值得舍弃一些性能。 -在克隆体敲门等待的情况下，即使单核处理器系统也能从并发中受益，因为它可以从等待（阻塞）的任务切换到准备运行的任务。但是如果所有任务都可以一直运行那么切换的成本反而会使任务变慢，在这种情况下，如果你有多个进程，并发通常只会有意义。 +在克隆体敲门等待的情况下，即使单核处理器系统也能从并发中受益，因为它可以从等待（阻塞）的任务切换到准备运行的任务。但是如果所有任务都可以一直运行那么切换的成本反而会使任务变慢，在这种情况下，并发只在如果你有多个处理器的情况下有意义。 -如果你正在尝试破解某种密码，在同一时间内参与破解的线程越多，你越快得到答案的可能性就越大。每个线程都能持续使用你所分配的处理器时间，在这种情况下（CPU 密集型问题），你代码中的线程数应该和你拥有的处理器的核心数保持一致。 +假设你正在尝试破解某种密码，在同一时间内参与破解的线程越多，你越快得到答案的可能性就越大。每个线程都能持续使用你所分配的处理器时间，在这种情况下（CPU 密集型问题），你代码中的线程数应该和你拥有的处理器的核心数保持一致。 -在接听电话的客户服务部门，你只有一定数量的员工，但是你的部门可能会打来很多电话。这些员工（处理器）一次只能接听一个电话直到打完，此时其它打来的电话必须排队等待。 +在接听电话的客户服务部门，你只有一定数量的员工，但是你的部门可能会收到很多电话。这些员工（处理器）一次只能接听一个电话直到打完，此时其它打来的电话必须排队等待。 在“鞋匠和精灵”的童话故事中，鞋匠有很多工作要做，当他睡着时，出现了一群精灵来为他制作鞋子。这里的工作是分布式的，但即使使用大量的物理处理器，在制造鞋子的某些部件时也会产生限制——例如，如果鞋底的制作时间最长，这就限制了鞋子的制作速度，这也会改变你设计解决方案的方式。 -因此，你要解决的问题推动了解决方案的设计。将一个问题分解成“独立运行”的子任务，这是一种美好的抽象，然后就是残酷的现实：物理现实不断地侵入和动摇这个抽象。 +因此，你要解决的问题驱动了方案的设计。将一个问题分解成“独立运行”的子任务，这是一种美好的抽象，然后就是实际发生的现实：物理现实不断干扰和动摇这个抽象。 -这只是问题的一部分：考虑一个制作蛋糕的工厂。我们以某种方式把制作蛋糕的任务分给了工人们，但是现在是时候让工人把蛋糕放在盒子里了。那里有一个盒子，准备存放蛋糕。但是在工人把蛋糕放进盒子之前，另一个工人就冲过去，把蛋糕放进盒子里，砰！这两个蛋糕撞到一起砸坏了。这是常见的“共享内存”问题，会产生所谓的竞态条件（race condition），其结果取决于哪个工人能先把蛋糕放进盒子里（通常使用锁机制来解决问题，因此一个工作人员可以先抓住一个盒子并防止蛋糕被砸烂）。 +这只是问题的一部分：考虑一个制作蛋糕的工厂。我们以某种方式把制作蛋糕的任务分给了工人们，现在是时候让工人把蛋糕放在盒子里了。那里有一个准备存放蛋糕的盒子。但是在一个工人把蛋糕放进盒子之前，另一个工人就冲过去，把蛋糕放进盒子里，砰！这两个蛋糕撞到一起砸坏了。这是常见的“共享内存”问题，会产生所谓的竞态条件（race condition），其结果取决于哪个工人能先把蛋糕放进盒子里（通常使用锁机制来解决问题，因此一个工作人员可以先抓住一个盒子并防止蛋糕被砸烂）。 -当“同时”执行的任务相互干扰时，就会出现问题。这可能以一种微妙而偶然的方式发生，因此可以说并发是“可以论证的确定性，但实际上是不确定性的”。也就是说，假设你很小心地编写并发程序，而且通过了代码检查可以正确运行。然而实际上，我们编写的并发程序大部分情况下都能正常运行，但是在一些情况下会失败。这些情况可能永远不会发生，或者在你在测试期间几乎很难发现它们。实际上，编写测试代码通常无法为并发程序生成故障条件。由此产生的失败只会偶尔发生，因此它们以客户投诉的形式出现。这是学习并发中最强有力的论点之一：如果你忽略它，你可能会受伤。 +当“同时”执行的任务相互干扰时，就会出现问题。这可能以一种微妙而偶然的方式发生，因此可以说并发是“可以论证的确定性，但实际上是不确定性的”。也就是说，假设你很小心地编写并发程序，而且通过了代码检查可以正确运行。然而实际上，我们编写的并发程序大部分情况下都能正常运行，但是在一些特定情况下会失败。这些情况可能永远不会发生，或者在你在测试期间几乎很难发现它们。实际上，编写测试代码通常无法为并发程序生成故障条件。由此产生的失败只会偶尔发生，因此它们以客户投诉的形式出现。这是学习并发中最强有力的论点之一：如果你忽略它，你可能会受伤。 因此，并发似乎充满了危险，如果这让你有点害怕，这可能是一件好事。尽管 Java 8 在并发性方面做出了很大改进，但仍然没有像编译时验证 (compile-time verification) 或受检查的异常 (checked exceptions) 那样的安全网来告诉你何时出现错误。关于并发，你只能依靠自己，只有知识渊博、保持怀疑和积极进取的人，才能用 Java 编写可靠的并发代码。