#kill -9 $(ps -ef | grep hnlinux) //方法一 过滤出hnlinux用户进程 
#kill -u hnlinux //方法二
# kill -HUP pid

kill可将指定的信息送至程序。预设的信息为SIGTERM(15)，可将指定程序终止。若仍无法终止该程序，可使用SIGKILL(9)信息尝试强制删除程序。程序或工作的编号可利用ps指令或jobs指令查看。

***

强杀一个线程带来的后果，所有这个线程正在使用的资源我们也别想回收了。

我们退出线程的手段是通知它们，“时间到啦，是时候收工啦”，然后等着它们一个个干完手头的工作，还原使用的资源。
其实严格来说，锁也算一种资源。当我们使用多个线程，去访问一个共享对象时，不可避免的要使用锁来做线程同步（当然了，你可以说用 lock-free ，但lock-free并不是万金油，在逻辑上必须进行条件等待的时候你还是得乖乖等待）。
	
当我们的一个线程获取了一个锁，正在访问某个共享方法的时候（比如调一个API啊，打印一个日志啊，balabala），还没来得及解锁就被咔嚓了，那这个锁就永远不会被解掉了，于是所有依赖这个锁的其它线程都华丽丽的死锁掉了。

有N种方法可以解决无限循环导致线程不会退出的情形。最常规的方法是用一个全局标记做退出通知：

我们处理耗时操作的时候，往往不会在主线程中进行，因为那会导致主线程的假死。如果主线程负责了GUI，那么GUI也就死掉了。因此常规的处理方法是开启一个线程专门执行耗时操作。

在这个时候，如果用户希望Cancel掉这个耗时操作，一般的做法是停止操作并退出工作线程。这就要求我们能够把一个完整的耗时操作分解成若干小粒度的，不怎么耗时的操作。

（1） 互斥条件： 一个资源每次只能被一个进程（线程）使用。 
（2） 请求与保持条件： 一个进程（线程）因请求资源而阻塞时，对已获得的资源保持不放。 
（3） 不剥夺条件: 此进程（线程）已获得的资源，在末使用完之前，不能强行剥夺。 
（4） 循环等待条件: 多个进程（线程）之间形成一种头尾相接的循环等待资源关系。
		假如我们的程序满足了这些条件，就会导致死锁的发生。
有一种说法是，我的进程要退出了，这时候我不想等，也不需要等待线程的返回，干脆利落的杀掉所有线程直接退出程序就好了。
是的，如果我们的程序只是一个简单的小程序（比如上文的fibonacci计算），这种方式不会有什么问题。
现实开发中，我们往往会遇到更多让我们忍不住拿起“武器”把线程杀一杀的时候。遇到这种情形，首先需要告诉自己一定要冷静，因为杀死一个线程，是我们迫不得已的最后手段。它往往只能掩盖住表面的问题，而让真正的漏洞存活下去；并且很可能引起一些其它的随机的运行错误。

std::terminate
std::terminate() 为 C++ 运行时在异常处理因下列原因失败时调用：
任何情况下， std::terminate 调用当前安装的 std::terminate_handler 。默认的 std::terminate_handler 调用 std::abort 。
(C++11 前)
若析构函数在栈回溯时重设 terminate_handler ，且后面的回溯导致调用 terminate ，则在 throw 表达式的结尾安装的处理函数会得到调用。（注意：重抛出是否应用新处理函数是有歧义的）
(C++11 后)
若析构函数在栈回溯时重设 terminate_handler ，则若后面的栈回溯导致调用 terminate ，调用哪个处理函数是未指定的。