Merge commit 'dd987c4df92807b142b0dbbfe3c6053534c6190c'

docs/book/24-Concurrent-Programming.md

@@ -120,12 +120,96 @@ _并行_
 因此，并发似乎充满了危险，如果这让你有点害怕，这可能是一件好事。尽管Java 8在并发性方面做出了很大改进，但仍然没有像编译时验证或检查异常那样的安全网来告诉您何时出现错误。通过并发，您可以自己动手，只有知识渊博，可疑和积极，才能用Java编写可靠的并发代码。
 
 <!-- Concurrency is for Speed -->
-## 针对速度
+<!-- 不知道是否可以找到之前翻译的针对速度感觉太直了 -->
+## 并发为速度而生
 
+在听说并发编程的问题之后，你可能会想知道它是否值得这么麻烦。答案是“不，除非你的程序运行速度不够快。”并且在决定它没有之前你会想要仔细思考。不要随便跳进并发编程的悲痛之中。如果有一种方法可以在更快的机器上运行您的程序，或者如果您可以对其进行分析并发现瓶颈并在该位置交换更快的算法，那么请执行此操作。只有在显然没有其他选择时才开始使用并发，然后仅在孤立的地方。
+
+速度问题一开始听起来很简单：如果你想要一个程序运行得更快，将其分解成碎片并在一个单独的处理器上运行每个部分。由于我们能够提高时钟速度流（至少对于传统芯片），速度的提高是出现在多核处理器的形式而不是更快的芯片。为了使你的程序运行得更快，你必须学习利用那些超级处理器，这是并发性给你的一个建议。
+
+使用多处理器机器，可以在这些处理器之间分配多个任务，这可以显着提高吞吐量。强大的多处理器Web服务器通常就是这种情况，它可以在程序中为CPU分配大量用户请求，每个请求分配一个线程。
+
+但是，并发性通常可以提高在单个处理器上运行的程序的性能。这听起来像是一个双向的。如果考虑一下，由于上下文切换的成本增加（从一个任务更改为另一个任务），在单个处理器上运行的并发程序实际上应该比程序的所有部分顺序运行具有更多的开销。在表面上，将程序的所有部分作为单个任务运行并节省上下文切换的成本似乎更便宜。
+
+可以产生影响的问题是阻塞。如果你的程序中的一个任务由于程序控制之外的某些条件（通常是I/O）而无法继续，我们会说任务或线程阻塞（在我们的科幻故事中，克隆体已敲门而且是等待它打开）。如果没有并发性，整个程序就会停止，直到外部条件发生变化。但是，如果使用并发编写程序，则当一个任务被阻止时，程序中的其他任务可以继续执行，因此程序继续向前移动。实际上，从性能的角度来看，在单处理器机器上使用并发是没有意义的，除非其中一个任务可能阻塞。
+
+单处理器系统中性能改进的一个常见例子是事件驱动编程，特别是用户界面编程。考虑一个程序执行一些长时间运行操作，从而最终忽略用户输入和无响应。如果你有一个“退出”按钮，你不想在你编写的每段代码中轮询它。这会产生笨拙的代码，无法保证程序员不会忘记执行检查。没有并发性，生成响应式用户界面的唯一方法是让所有任务定期检查用户输入。通过创建单独的执行线程来响应用户输入，该程序保证了一定程度的响应。
+
+实现并发的直接方法是在操作系统级别，使用与线程不同的进程。进程是一个在自己的地址空间内运行的自包含程序。进程很有吸引力，因为操作系统通常将一个进程与另一个进程隔离，因此它们不会相互干扰，这使得进程编程相对容易。相比之下，线程共享内存和I/O等资源，因此编写多线程程序时遇到的困难是在不同的线程驱动的任务之间协调这些资源，一次不能通过多个任务访问它们。
+<!-- 文献引用未加，因为暂时没看到很好的解决办法 -->
+有些人甚至提倡将进程作为并发的唯一合理方法[^1]，但不幸的是，通常存在数量和开销限制，以防止它们在并发频谱中的适用性（最终你习惯了标准的并发性克制，“这种方法适用于一些情况但不适用于其他情况”）
+
+一些编程语言旨在将并发任务彼此隔离。这些通常被称为_函数式语言_，其中每个函数调用不产生其他影响（因此不能与其他函数干涉），因此可以作为独立的任务来驱动。Erlang就是这样一种语言，它包括一个任务与另一个任务进行通信的安全机制。如果您发现程序的一部分必须大量使用并发性并且您在尝试构建该部分时遇到了过多的问题，那么您可能会考虑使用专用并发语言创建程序的那一部分。
+<!-- 文献标记 -->
+Java采用了更传统的方法[^2]，即在顺序语言之上添加对线程的支持而不是在多任务操作系统中分配外部进程，线程在执行程序所代表的单个进程中创建任务交换。
+
+并发性会带来成本，包括复杂性成本，但可以通过程序设计，资源平衡和用户便利性的改进来抵消。通常，并发性使您能够创建更加松散耦合的设计;否则，您的代码部分将被迫明确标注通常由并发处理的操作。
 
 <!-- The Four Maxims of Java Concurrency -->
 ## 四句格言
 
+在经历了多年的Java并发之后，我总结了以下四个格言：
+>1.不要这样做
+>
+>2.没有什么是真的，一切可能都有问题
+>
+>3.它起作用,并不意味着它没有问题
+>
+>4.你仍然必须理解它
+
+这些特别是关于Java设计中的问题，尽管它也可以应用于其他一些语言。但是，确实存在旨在防止这些问题的语言。
+
+### 1.不要这样做
+
+（不要自己动手）
+
+避免纠缠于并发产生的深层问题的最简单方法就是不要这样做。虽然它是诱人的，并且似乎足够安全，可以尝试做简单的事情，但它存在无数、微妙的陷阱。如果你可以避免它，你的生活会更容易。
+
+证明并发性的唯一因素是速度。如果你的程序运行速度不够快 - 在这里要小心，因为只是希望它运行得更快是不合理的 - 首先应用一个分析器（参见代码校验章中分析和优化）来发现你是否可以执行其他一些优化。
+
+如果您被迫进行并发，请采取最简单，最安全的方法来解决问题。使用众所周知的库并尽可能少地编写自己的代码。有了并发性，就没有“太简单了”。自负才是你的敌人。
+
+### 2.没有什么是真的，一切可能都有问题
+
+没有并发性的编程，你会发现你的世界有一定的顺序和一致性。通过简单地将变量赋值给某个值，很明显它应该始终正常工作。
+
+在并发领域，有些事情可能是真的而有些事情却不是，你必须认为没有什么是真的。你必须质疑一切。即使将变量设置为某个值也可能或者可能不会按预期的方式工作，并且从那里开始走下坡路。我已经很熟悉的东西，认为它显然有效但实际上并没有。
+
+在非并发程序中你可以忽略的各种事情突然变得非常重要。例如，您必须知道处理器缓存以及保持本地缓存与主内存一致的问题。您必须了解对象构造的深度复杂性，以便您的构造对象不会意外地将数据暴露给其他线程进行更改。问题还有很多。
+
+虽然这些主题太复杂，无法为您提供本章的专业知识（再次参见Java Concurrency in Practice），但您必须了解它们。
+
+### 3.它起作用,并不意味着它没有问题
+
+您可以轻松编写一个似乎可以工作，但实际上是有问题的并发程序，并且该问题仅在最极限的条件下显示出来 - 在您部署程序后不可避免地会出现用户问题。
+
+- 你不能证明并发程序是正确的，你只能（有时）证明它是不正确的。
+- 大多数情况下你甚至不能这样做：如果它有问题，你可能无法检测到它。
+- 您通常不能编写有用的测试，因此您必须依靠代码检查结合深入的并发知识来发现错误。
+- 即使是有效的程序也只能在其设计参数下工作。当超出这些设计参数时，大多数并发程序会以某种方式失败。
+
+在其他Java主题中，我们培养了一种感觉-决定论。一切都按照语言的承诺（或隐含）进行，这是令人欣慰和期待的 - 毕竟，编程语言的目的是让机器做我们想要的。从确定性编程的世界进入并发编程领域，我们遇到了一种称为[Dunning-Kruger](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)效应的认知偏差，可以概括为“你知道的越多，你认为你知道得越多。”这意味着“......相对不熟练的人拥有着虚幻的优越感，错误地评估他们的能力远高于实际。
+
+我自己的经验是，无论你是多么确定你的代码是线程安全的，它可能已经无效了。你可以很容易地了解所有的问题，然后几个月或几年后你会发现一些概念让你意识到你编写的大多数内容实际上都容易受到并发错误的影响。当某些内容不正确时，编译器不会告诉您。为了使它正确，你必须在研究代码时掌握前脑的所有并发问题。
+
+在Java的所有非并发领域，“没有明显的错误和没有明显的编译错误”似乎意味着一切都好。对于并发，它没有任何意义。你可以在这个情况下做的最糟糕的事情是“自信”。
+
+### 4.你必须仍然理解
+
+在格言1-3之后，您可能会对并发性感到害怕，并且认为，“到目前为止，我已经避免了它，也许我可以继续保留它。
+
+这是一种理性的反应。您可能知道其他编程语言更好地设计用于构建并发程序 - 甚至是在JVM上运行的程序（从而提供与Java的轻松通信），例如Clojure或Scala。为什么不用这些语言编写并发部分并将Java用于其他所有部分呢？
+
+唉，你不能轻易逃脱：
+
+- 即使你从未明确地创建一个线程，你可能使用的框架 - 例如，Swing图形用户界面（GUI）库，或者像**Timer** clas那样简单的东西。
+- 这是最糟糕的事情：当您创建组件时，您必须假设这些组件可能在多线程环境中重用。即使你的解决方案是放弃并声明你的组件“不是线程安全的”，你仍然必须知道这样的声明是重要的，它是什么意思？
+
+人们有时会认为并发性太难，不能包含在介绍该语言的书中。他们认为并发是一个可以独立对待的独立主题，并且它在日常编程中出现的少数情况（例如图形用户界面）可以用特殊的习语来处理。如果你可以避免它，为什么要介绍这样的复杂的主题。
+
+唉，如果只是这样的话，那就太好了。但不幸的是，您无法选择何时在Java程序中出现线程。仅仅你从未写过自己的线程，并不意味着你可以避免编写线程代码。例如，Web系统是最常见的Java应用程序之一，本质上是多线程的Web服务器通常包含多个处理器，而并行性是利用这些处理器的理想方式。就像这样的系统看起来那么简单，你必须理解并发才能正确地编写它。
+
+Java是一种多线程语言，如果您了解它们是否存在并发问题。因此，有许多Java程序正在使用中，或者只是偶然工作，或者大部分时间工作并且不时地发生问题，因为。有时这种问题是相对良性的，但有时它意味着丢失有价值的数据，如果你没有意识到并发问题，你最终可能会把问题放在其他地方而不是你的代码中。如果将程序移动到多处理器系统，则可以暴露或放大这些类型的问题。基本上，了解并发性使您意识到正确的程序可能会表现出错误的行为。
 
 <!-- The Brutal Truth -->
 ## 残酷的真相
@@ -166,8 +250,9 @@ _并行_
 <!-- Summary -->
 ## 本章小结
 
+[^1]:例如,Eric-Raymond在“VIIX编程艺术”（Addison-Wesley，2004）中提出了一个很好的案例。
 
-
+[^2]:可以说，试图将并发性用于后续语言是一种注定要失败的方法，但你必须得出自己的结论
 <!-- 分页 -->
 
 <div style="page-break-after: always;"></div>