问题描述
我正在阅读 Elixir in Action书由SašaJurić撰写，在第一章中，它说：
I am reading "Elixir in Action" book by Saša Jurić, and in the first chapter it says:
Java线程不是这样吗？我的意思是当Java线程崩溃时，它也不会崩溃其他线程 - 特别是如果我们正在查看请求处理线程（允许从这个disucussion中排除 main 线程） / p>
Isn't that true for Java threads as well? I mean when Java thread crashes, it too does not crash other threads - especially, if we are looking at request-processing threads (lets exclude the main thread from this disucussion)
推荐答案
在我之后重复：这是不同的范例
大声说出20遍 - 这是我们现在的口头禅。
Say that aloud 20 times or so -- it is our mantra for the moment.
如果我们真的必须比较苹果和橘子，我们至少考虑果实的共同方面相交。
If we really must compare apples and oranges, let's at least consider where the common aspects of "being fruit" intersect.
Java对象是Java程序员的基本计算单位。也就是说，一个对象 - 基本上是具有比C ++更严格执行的封装的胳膊和腿的结构体是您为世界建模的主要工具。你认为这个对象知道/拥有数据{X，Y，Z}并且在其上执行函数{A（），B（），C（）}，将数据传递到任何地方，并且可以通过调用函数/方法被定义为它们的公共接口的一部分，它是一个名词，而这个名词是的东西。也就是说，您围绕这些计算单位来指导您的思维过程。默认的情况是在对象之间发生的事情按顺序发生，并且崩溃会中断该序列。它们被称为对象，因此（如果我们忽略了Alan Kay的本义），我们得到对象方向。
Java "objects" are a Java programmer's basic unit of computation. That is, an "object" -- basically a struct with arms and legs that has encapsulation somewhat more strictly enforced than in C++ -- is the primary tool with which you model the world. You think "This object knows/has Data {X,Y,Z} and performs Functions {A(),B(),C()} over it, carries the Data everywhere it goes, and can communicate with other objects by calling functions/methods defined as part of their public interface. It is a noun, and that noun does stuff.". That is to say, you orient your thought process around these units of computation. The default case is that things that happen amongst the objects occur in sequence, and a crash interrupts that sequence. They are called "objects" and hence (if we disregard Alan Kay's original meaning) we get "object orientation".
Erlang进程是Erlang程序员的基本单位计算。一个过程 - 基本上是一个独立的顺序程序运行在自己的时间和空间 - 是Erlanger模拟世界的主要工具。类似于Java对象如何定义一个封装级别，Erlang进程也定义了封装级别，但是在Erlang的情况下，计算单元完全相互切断。您不能在另一个进程上调用方法或函数，也不能访问其中存在的任何数据，也不会在与其他进程相同的时间上下文中运行一个进程，并且不能保证消息接收相对的顺序到可能发送消息的其他进程。他们也可以完全在不同的行星上（而且，想到这一点，这实际上是合理的）。他们可能彼此独立地崩溃，而其他过程只有在故意选择受到影响的情况下才会受到影响（即使这涉及到消息传递：本质上注册从死亡过程中获得自杀笔记，本身不能保证以任何形式获得）相对于整个系统的顺序，您可以选择或不可以选择反应）。
Erlang "processes" are an Erlang programmer's basic unit of computation. A "process" -- basically a self-contained sequential program running in its own time and space -- is the primary tool with which an Erlanger models the world. Similar to how Java objects define a level of encapsulation, Erlang processes also define the level of encapsulation, but in the case of Erlang the units of computation are completely cut off from one another. You cannot call a method or function on another process, nor can you access any data that lives within it, nor does one process even run within the same timing context as any other processes, and there is no guarantee about the ordering of message reception relative to other processes which may be sending messages. They may as well be on different planets entirely (and, come to think of it, this is actually plausible). They can crash independently of one another and the other processes are only impacted if they have deliberately elected to be impacted (and even this involves messaging: essentially registering to receive a suicide note from the dead process which itself is not guaranteed to arrive in any sort of order relative to the system as a whole, to which you may or may not choose to react).
Java在复合算法中直接处理复杂性：对象如何协同工作解决问题。它被设计为在单个执行上下文中执行此操作，Java中的默认情况是顺序执行。 Java中的多个线程表示多个运行的上下文，并且是一个非常复杂的主题，因为在不同的定时上下文中的影响活动（整个系统，因此防御性编程，异常方案等）。在Java 中说多线程意味着与Erlang不同的东西，实际上这在Erlang中从来没有说过，因为它总是基本的情况。请注意，Java线程意味着隔离属于时间，而不是内存或可见的引用 - Java中的可见性是通过选择私有和公共来手动控制的;系统的普遍可访问元素必须被设计为线程安全，并可通过排队机制重新进行顺序化，或采用锁定机制。简而言之：调度是线程/并发Java程序中的手动管理问题。
Java deals with complexity directly in compound algorithms: how objects work together to solve a problem. It is designed to do this within a single execution context, and the default case in Java is sequential execution. Multiple threads in Java indicates multiple running contexts and is a very complex topic because of the impact activity in different timing contexts have on one another (and the system as a whole: hence defensive programming, exception schemes, etc.). Saying "multi-threaded" in Java means something different than it does in Erlang, in fact this is never even said in Erlang because it is always the base case. Note here that Java threads imply segregation as pertains to time, not memory or visible references -- visibility in Java is controlled manually by choosing what is private and what is public; universally accessible elements of a system must be either designed to be "threadsafe" and reentrant, sequentialized via queueing mechanisms, or employ locking mechanisms. In short: scheduling is a manually managed issue in threaded/concurrent Java programs.
Erlang根据执行时间（调度），内存访问和参考可见性并且这样做通过将其完全隔离来简化算法的每个组件。这不仅仅是默认情况，这是这种计算模式下唯一可用的情况。这是因为一旦处理序列的一部分与消息屏障相交，就不会完全知道任何给定操作的顺序 - 因为消息本质上是网络协议，并且没有可以保证在给定的内部执行的方法调用上下文。这将类似于为每个对象创建一个JVM实例，并且只允许它们跨套接字进行通信 - 这在Java中是非常麻烦的，但是Erlang被设计为工作的方式（顺便提及，这也是概念的基础写Java微服务，如果一个沟通了面向行李的流行语趋向于需要 - 默认情况下，Erlang程序是一组微服务器。它的所有关于权衡。
Erlang separates each processes' running context in terms of execution timing (scheduling), memory access and reference visibility and in doing so simplifies each component of an algorithm by isolating it completely. This is not just the default case, this is the only case available under this model of computation. This comes at the cost of never knowing exactly the sequence of any given operation once a part of your processing sequences crosses a message barrier -- because messages are all essentially network protocols and there are no method calls that can be guaranteed to execute within a given context. This would be analogous to creating a JVM instance per object, and only permitting them to communicate across sockets -- that would be ridiculously cumbersome in Java, but is the way Erlang is designed to work (incidentally, this is also the basis of the concept of writing "Java microservices" if one ditches the web-oriented baggage the buzzword tends to entail -- Erlang programs are, by default, swarms of microservices). Its all about tradeoffs.
这是不同的范例。我们可以找到最接近的共性是说从程序员的角度来看，Erlang进程类似于Java对象。如果我们必须找到一些东西来比较Java线程，那么我们根本不会在Erlang中找到类似的东西，因为Erlang没有这样的可比性的概念。要打死一匹死马：这些是不同的范例。如果您在Erlang中写下几个不平凡的程序，这将变得很明显。
These are different paradigms. The closest commonality we can find is to say that from the programmer's perspective, Erlang processes are analogous to Java objects. If we must find something to compare Java threads to... well, we're simply not going to find something like that in Erlang, because there is no such comparable concept in Erlang. To beat a dead horse: these are different paradigms. If you write a few non-trivial programs in Erlang this will become readily apparent.
请注意，我在说这是不同的范例，但还没有触及OOP vs FP的主题。 Java中的思维和Erlang的思考之间的区别比OOP vs FP更为根本。
Note that I'm saying "these are different paradigms" but have not even touched the topic of OOP vs FP. The difference between "thinking in Java" and "thinking in Erlang" is more fundamental than OOP vs FP.
尽管Erlang的并发导向或进程导向的基础更接近艾伦·凯（Alan Kay）在创造面向对象这个术语时所想到的，这不是真的。 Kay得到的是，通过将您的计算机切割成离散的块，可以降低系统的认知复杂性，隔离是必要的。 Java以一种使其基本上仍然基本上是程序性的方式实现，但结构代码围绕着称为类定义的高阶调度闭包的特殊语法。 Erlang通过将每个对象的运行上下文分割来实现。这意味着Erlang的东西不能相互调用方法，但Java东西可以。这意味着Erlang的东西可能会孤立地崩溃，但Java东西不能。这个基本差异来源于广泛的含义 - 因此不同范式。权衡。
While it is true that Erlang's "concurrency oriented" or "process oriented" foundation is closer to what Alan Kay had in mind when he coined the term "object oriented", that is not really the point here. What Kay was getting at was that one can reduce the cognitive complexity of a system by cutting your computrons into discrete chunks, and isolation is necessary for that. Java accomplishes this in a way that leaves it still fundamentally procedural in nature, but structures code around a special syntax over higher-order dispatching closures called "class definitions". Erlang does this by splitting the running context up per object. This means Erlang thingies can't call methods on one another, but Java thingies can. This means Erlang thingies can crash in isolation but Java thingies can't. A vast number of implications flow from this basic difference -- hence "different paradigms". Tradeoffs.
这篇关于Erlang进程与Java线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！