进程也可以称为是“任务”。操作系统要想执行一个具体的“动作”，就需要创建出一个对应的进程。
一个程序在没有运行的时候，它仅仅是一个“可执行的文件”，一旦程序跑起来了，就变成了一个进程了。
为了实现并发编程，同时执行多个任务，就引入了“多进程编程”。把一个很大的任务，拆分成若干个很小的任务，就可以创建多个进程，每个进程分别负责其中的一部分任务。
多进程编程也带来了一个很大的问题：创建/销毁进程，比较重量或比较低效。
为了避免这样的问题，就引入了线程。
每个线程都是一个独立的执行流。一个进程包含了一个或多个线程。我们的初心就是为了能够实现并发，多个进程能够实现并发,同样多个线程也能实现并发。但是多线程要比多进程更加高效和轻量。创建线程/销毁线程比创建进程/销毁进程更加高效和轻量。所以，一般情况下，会使用多线程来进行开发。
因此，在Java这个圈子里面，大部分的并发编程都是通过多线程的方式来实现的。
难道多进程就一无是处吗？
当然不是，多进程也有它自己独特的优势。
进程相比于线程的优势：
进程的“独立性”更好。比如在操作系统上，同一时刻运行着很多个进程：
同一时刻可能同时运行着成百上千的进程，但是每个进程之间都不相互干扰，如果某一个进程挂了不会影响到其他的进程，因为每个进程有各自的地址空间。每个进程之间井水不犯河水，自己经营着自己的一亩三分地，由我们的操作系统统一进行统筹管理，如果某个进程出现了一些意外，无法正常工作，直接奔溃了，那么也仅仅是这个进程自身挂了，不会出现把其他进程也带走的情况。所以说，进程“独立性”这一点是非常重要的。
相比之下，由于多个线程之间，共用着一个进程的地址空间。这就导致了某个线程挂了，就很可能会直接把整个进程带走，那么这个进程里面的其他线程也就没了。
正是因为这一点，进程要比线程来的更加稳定一点。虽然进程没有线程那么高效，但是它的独立性带来的稳定是非常关键的。
多进程编程主要做的事情：
站在操作系统的角度（以Linux为例），提供了很多和多进程编程相关的接口：进程创建、进程终止、进程等待、进程程序替换、进程间通信......
而在Java中对系统提供的这些操作进行了限制，最终给用户只提供了两个操作：进程创建和进程等待。虽然功能受限，但是当前也是足够用了。
案例分析：
比如有一个类似在线OJ刷题的平台，那么它就有一个服务器进程（接受用户的请求，返回响应），用户提交的代码其实也是一个独立的逻辑，那么这个逻辑是使用多线程执行好，还是多进程呢？
那么对于这里用户提交的代码，一定是要通过“多进程”的方式来执行的！！！因为我们无法控制用户到底提交了什么代码，代码很可能是存在问题的，很可能一运行就会出现崩溃的情况。那么如果使用多线程，就很可能会导致用户代码直接把整个服务器进程都给带走了的情况。因为一个服务器同时要给很多个用户提供服务，但是不能因为一个用户问题就挂了服务器，导致其他用户也访问不了。而且在真实情况下，用户是非常非常多的，是不能保证每一个用户的代码都是没毛病的！
