在编程中，并发是独立的组合 执行进程，而并行是同时执行 计算的(可能相关的)。 -安德鲁·格兰德

And

Concurrency is the composition of independently executing computations. Concurrency is a way to structure software, particularly as a way to write clean code that interacts well with the real world. It is not parallelism. Concurrency is not parallelism, although it enables parallelism. If you have only one processor, your program can still be concurrent but it cannot be parallel. On the other hand, a well-written concurrent program might run efficiently in parallel on a multiprocessor. That property could be important... - Rob Pike -

为了理解其中的区别，我强烈建议你去看看Rob Pike(Golang的创作者之一)的视频。并发不是并行

我会试着用我自己的方式来解释它，它可能不是计算机术语，但它能给你一个大概的概念。

让我们以家务为例:洗碗，倒垃圾，修剪草坪等，我们有三个人(线程)A, B, C来做这些事情

并发: 三个人独立地开始不同的任务，例如，

A --> cleaning dishes
B --> taking out trash 
C --> mowing the lawn 

在这里，任务的顺序是不确定的，响应取决于工作量

并行: 在这里，如果我们想要提高吞吐量，我们可以分配多个人来完成一项任务，例如，清洁盘子，我们分配两个人，A擦洗盘子，B洗盘子，这可能会提高吞吐量。

洗碗:

A --> soaping the dishes
B --> washing the dishes

等等

希望这能给你一些启发!现在转到其他答案中解释的技术术语;)

虽然没有完整 对并行和并发这两个术语的区别达成一致， 许多作者做了以下区分:

在并发计算中，一个程序可以在任意时刻执行多个任务。 在并行计算中，一个程序是多个任务紧密合作的程序 解决一个问题。

所以并行程序是并发的，但是像多任务操作系统这样的程序也是并发的，即使它运行在一台带有 只有一个核心，因为多个任务可以在任何时刻进行。

来源:Peter Pacheco的《并行编程介绍》

并发性提供了一种构建解决方案的方法，以解决可能(但不一定)可并行的问题， 并发性是关于结构，并行性是关于执行。

我在一些博客上找到了这个内容。认为它是有用的和相关的。

并发性和并行性不是一回事。两个任务T1和T2是并发的，如果这两个任务的执行顺序不是预先确定的，

T1可以在T2之前执行和完成， T2可以在T1之前执行和完成， T1和T2可以在同一个时间实例中同时执行(并行性)， T1和T2可以交替执行， .．. 如果操作系统安排两个并发线程在一个单核非smt非cmp处理器上运行，您可能会得到并发性而不是并行性。并行在多核、多处理器或分布式系统上是可能的。

并发性通常被认为是程序的一种属性，是一个比并行性更普遍的概念。

来源:https://blogs.oracle.com/yuanlin/entry/concurrency_vs_parallelism_concurrent_programming

不同的人在许多不同的具体情况下讨论不同类型的并发性和并行性，因此需要一些抽象来涵盖它们的共同性质。

The basic abstraction is done in computer science, where both concurrency and parallelism are attributed to the properties of programs. Here, programs are formalized descriptions of computing. Such programs need not to be in any particular language or encoding, which is implementation-specific. The existence of API/ABI/ISA/OS is irrelevant to such level of abstraction. Surely one will need more detailed implementation-specific knowledge (like threading model) to do concrete programming works, the spirit behind the basic abstraction is not changed.

第二个重要的事实是，作为一般属性，并发性和并行性可以在许多不同的抽象中共存。

关于一般的区别，请参阅并发和并行的基本观点的相关答案。(还有一些链接包含一些其他来源。)

并发编程和并行编程是用一些系统实现这些一般属性的技术，这些系统公开了可编程性。系统通常是编程语言及其实现。

A programming language may expose the intended properties by built-in semantic rules. In most cases, such rules specify the evaluations of specific language structures (e.g. expressions) making the computation involved effectively concurrent or parallel. (More specifically, the computational effects implied by the evaluations can perfectly reflect these properties.) However, concurrent/parallel language semantics are essentially complex and they are not necessary to practical works (to implement efficient concurrent/parallel algorithms as the solutions of realistic problems). So, most traditional languages take a more conservative and simpler approach: assuming the semantics of evaluation totally sequential and serial, then providing optional primitives to allow some of the computations being concurrent and parallel. These primitives can be keywords or procedural constructs ("functions") supported by the language. They are implemented based on the interaction with hosted environments (OS, or "bare metal" hardware interface), usually opaque (not able to be derived using the language portably) to the language. Thus, in this particular kind of high-level abstractions seen by the programmers, nothing is concurrent/parallel besides these "magic" primitives and programs relying on these primitives; the programmers can then enjoy less error-prone experience of programming when concurrency/parallelism properties are not so interested.

Although primitives abstract the complex away in the most high-level abstractions, the implementations still have the extra complexity not exposed by the language feature. So, some mid-level abstractions are needed. One typical example is threading. Threading allows one or more thread of execution (or simply thread; sometimes it is also called a process, which is not necessarily the concept of a task scheduled in an OS) supported by the language implementation (the runtime). Threads are usually preemptively scheduled by the runtime, so a thread needs to know nothing about other threads. Thus, threads are natural to implement parallelism as long as they share nothing (the critical resources): just decompose computations in different threads, once the underlying implementation allows the overlapping of the computation resources during the execution, it works. Threads are also subject to concurrent accesses of shared resources: just access resources in any order meets the minimal constraints required by the algorithm, and the implementation will eventually determine when to access. In such cases, some synchronization operations may be necessary. Some languages treat threading and synchronization operations as parts of the high-level abstraction and expose them as primitives, while some other languages encourage only relatively more high-level primitives (like futures/promises) instead.

Under the level of language-specific threads, there come multitasking of the underlying hosting environment (typically, an OS). OS-level preemptive multitasking are used to implement (preemptive) multithreading. In some environments like Windows NT, the basic scheduling units (the tasks) are also "threads". To differentiate them with userspace implementation of threads mentioned above, they are called kernel threads, where "kernel" means the kernel of the OS (however, strictly speaking, this is not quite true for Windows NT; the "real" kernel is the NT executive). Kernel threads are not always 1:1 mapped to the userspace threads, although 1:1 mapping often reduces most overhead of mapping. Since kernel threads are heavyweight (involving system calls) to create/destroy/communicate, there are non 1:1 green threads in the userspace to overcome the overhead problems at the cost of the mapping overhead. The choice of mapping depending on the programming paradigm expected in the high-level abstraction. For example, when a huge number of userspace threads expected being concurrently executed (like Erlang), 1:1 mapping is never feasible.

The underlying of OS multitasking is ISA-level multitasking provided by the logical core of the processor. This is usually the most low-level public interface for programmers. Beneath this level, there may exist SMT. This is a form of more low-level multithreading implemented by the hardware, but arguably, still somewhat programmable - though it is usually only accessible by the processor manufacturer. Note the hardware design is apparently reflecting parallelism, but there is also concurrent scheduling mechanism to make the internal hardware resources being efficiently used.

在上面提到的每一层“线程”中，都涉及并发性和并行性。尽管编程接口变化很大，但它们都服从于一开始基本抽象所揭示的属性。