进程是系统进行资源分配的基本单位，有独立的内存地址空间；
线程是CPU调度的基本单位，没有单独地址空间，有独立的栈，局部变量，寄存器，程序计数器等
只有进程有自己的 address space，而这个 space 中经过合法申请的部分叫做 process space。Process space 之外的地址都是非法地址。
当一个线程向非法地址读取或者写入，无法确认这个操作是否会影响同一进程中的其它线程，所以只能是整个进程一起崩溃。
现代操作系统对于线程的支持方式不同，导致题主的问题在不同的操作系统下有不同的结果。
所谓现代的操作系统，是指支持多用户，支持并行处理的操作系统。鉴于此因，操作系统一般都设计成支持两种工作模式，user mode和kernel mode，这两种模式相互隔绝无法直接访问，避免用户程序对于底层资源的直接访问，通过system call的调用实现交互目的，从而实现操作系统对资源分配的公平和系统的高效率。
对于linux而言，其对线程的支持是在user mode内实现的，而linux的scheduler（任务调度器）却是工作在kernel mode的，对于linux的job scheduler而言，他的调度对象还是进程，线程这个概念对他而言是透明的。就像一个大公司的老板，他的管理单元是部门，不会细究部门内某个人的事情。所以，对于题主的问题在linux下，线程异常退出的结果就是其父进程也跟着退出，即使这个线程的父进程下的其他多个兄弟线程都工作正常。我们在平常的工作中应该经常遇到过由于某个java线程异常退出而导致整个tomcat进程重启或退出，就是由于这个原因。
而信奉扁平式管理的fans MS windows（win 2000？以后）以后及SUN的solaris 8（？）以后版本，他们的scheduler是可以直接对线程操作的，他们不仅像linux一样，为每一个进程维护相应的PCB（process control block），针对线程还维护了一套相应的Thread Control Block - TCB, 以实现context switch。 solaris甚至突破了一个进程调用多个线程的思路，衍生了多个进程对应更多个线程执行同一个任务的实现方式。在这种情况下是可以出现某个线程异常退出，但是没有影响其父进程和其他兄弟线程的工作状态的情况发生。
https://www.zhihu.com/question/22397613
进程（process）和线程（thread）是操作系统的基本概念，但是它们比较抽象，不容易掌握。
最近，我读到一篇材料，发现有一个很好的类比，可以把它们解释地清晰易懂。
1.
计算机的核心是CPU，它承担了所有的计算任务。它就像一座工厂，时刻在运行。
2.
假定工厂的电力有限，一次只能供给一个车间使用。也就是说，一个车间开工的时候，其他车间都必须停工。背后的含义就是，单个CPU一次只能运行一个任务。
3.
进程就好比工厂的车间，它代表CPU所能处理的单个任务。任一时刻，CPU总是运行一个进程，其他进程处于非运行状态。
4.
一个车间里，可以有很多工人。他们协同完成一个任务。
5.
线程就好比车间里的工人。一个进程可以包括多个线程。
6.
车间的空间是工人们共享的，比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的，每个线程都可以使用这些共享内存。
7.
可是，每间房间的大小不同，有些房间最多只能容纳一个人，比如厕所。里面有人的时候，其他人就不能进去了。这代表一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。
8.
一个防止他人进入的简单方法，就是门口加一把锁。先到的人锁上门，后到的人看到上锁，就在门口排队，等锁打开再进去。这就叫"互斥锁"（Mutual exclusion，缩写 Mutex），防止多个线程同时读写某一块内存区域。
9.
还有些房间，可以同时容纳n个人，比如厨房。也就是说，如果人数大于n，多出来的人只能在外面等着。这好比某些内存区域，只能供给固定数目的线程使用。
10.
这时的解决方法，就是在门口挂n把钥匙。进去的人就取一把钥匙，出来时再把钥匙挂回原处。后到的人发现钥匙架空了，就知道必须在门口排队等着了。这种做法叫做"信号量"（Semaphore），用来保证多个线程不会互相冲突。
不难看出，mutex是semaphore的一种特殊情况（n=1时）。也就是说，完全可以用后者替代前者。但是，因为mutex较为简单，且效率高，所以在必须保证资源独占的情况下，还是采用这种设计。
11.
操作系统的设计，因此可以归结为三点：
（1）以多进程形式，允许多个任务同时运行；
（2）以多线程形式，允许单个任务分成不同的部分运行；
（3）提供协调机制，一方面防止进程之间和线程之间产生冲突，另一方面允许进程之间和线程之间共享资源。
（完）
http://www.ruanyifeng.com/blog/2013/04/processes_and_threads.html