优化翻译 (#411)

* 对照原文和语境,修复了整段翻译

* 优化翻译

* fix 翻译错误

* fix 单词少了一截
This commit is contained in:
XuYanxin
2020-03-19 23:42:55 +08:00
committed by GitHub
parent 6096fafbea
commit 91c0847608

View File

@@ -117,7 +117,7 @@ _并行_
当“同时”执行的任务相互干扰时,会出现问题。他可以以如此微妙和偶然的方式发生,可能公平地说,并发性“可以说是确定性的,但实际上是非确定性的。”也就是说,你可以假设编写通过维护和代码检查正常工作的并发程序。然而,在实践中,编写仅看起来可行的并发程序更为常见,但是在适当的条件下,将会失败。这些情况可能会发生,或者很少发生,你在测试期间从未看到它们。实际上,编写测试代码通常无法为并发程序生成故障条件。由此产生的失败只会偶尔发生,因此它们以客户投诉的形式出现。
这是推动并发的最强有力的论据之一:如果你忽略它,你可能会被咬。
因此并发似乎充满了危险如果这让你有点害怕这可能是一件好事。尽管Java 8在并发性方面做出了很大改进但仍然没有像编译时验证检查异常那样的安全网来告诉你何时出现错误。通过并发,你可以自己动手,只有知识渊博,疑和积极才能用Java编写可靠的并发代码。
因此并发似乎充满了危险如果这让你有点害怕这可能是一件好事。尽管Java 8在并发性方面做出了很大改进但仍然没有像编译时验证(compile-time verification)或受检查异常(checked exceptions)那样的安全网来告诉你何时出现错误。通过并发,你只能依靠自己,只有知识渊博,保持怀疑和积极进取的人才能用Java编写可靠的并发代码。
<!-- Concurrency is for Speed -->
<!-- 不知道是否可以找到之前翻译的针对速度感觉太直了 -->
@@ -129,7 +129,7 @@ _并行_
使用多处理器机器可以在这些处理器之间分配多个任务这可以显着提高吞吐量。强大的多处理器Web服务器通常就是这种情况它可以在程序中为CPU分配大量用户请求每个请求分配一个线程。
但是,并发性通常可以提高在单个处理器上运行的程序的性能。这听起来像是一个双向的。如果考虑一下,由于上下文切换的成本增加(从一个任务更改为另一个任务),在单个处理器上运行的并发程序实际上应该比程序的所有部分顺序运行具有更多的开销。在表面上,将程序的所有部分作为单个任务运行并节省上下文切换的成本似乎更便宜。
但是,并发性通常可以提高在单个处理器上运行的程序的性能。这听起来有点违反直觉。如果考虑一下,由于上下文切换的成本增加(从一个任务更改为另一个任务),在单个处理器上运行的并发程序实际上应该比程序的所有部分顺序运行具有更多的开销。在表面上,将程序的所有部分作为单个任务运行并节省上下文切换的成本似乎更便宜。
可以产生影响的问题是阻塞。如果你的程序中的一个任务由于程序控制之外的某些条件通常是I/O而无法继续我们会说任务或线程阻塞在我们的科幻故事中克隆体已敲门而且是等待它打开。如果没有并发性整个程序就会停止直到外部条件发生变化。但是如果使用并发编写程序则当一个任务被阻止时程序中的其他任务可以继续执行因此程序继续向前移动。实际上从性能的角度来看在单处理器机器上使用并发是没有意义的除非其中一个任务可能阻塞。