对于操作系统来说，进程未响应的本质是什么？如何检测进程未响应？

以 Windows 来讲，每当用户操作窗口上的一个按钮或菜单，会产生一个事件（ Event ）。操作系统会把事件投递到应用程序的事件队列里。如果这个事件过了很久还没有被应用程序处理，那系统就会提示“未响应”。
我不太了解其他系统下的机制，不过应该也差不多。
应用程序未响应的原因很多，也许像你说的在占用 CPU，也可能是在等待 I/O 或者锁。

纠正一个名词，Windows 编程里面通常把这个事件叫做消息（ Message ）

个人理解是对于有限资源竞争过程中造成的死锁。

吃饭需要两个筷子，结果 A 程序拿到了一根筷子，B 程序也拿到了一根筷子。A/B 都不愿意释放自己手中的筷子，互相等待对方释放资源（筷子），以便于自己继续运行，最终因为谁都不释放资源造成程序死锁

同样吃饭需要两个筷子，A 程序功能拿到 2 个筷子，开始吃饭。此时 B 程序也要吃饭，发现没筷子了，系统告诉 B，让他等等，A 吃饭了，B 再去吃。但是 A 吃着吃着，出意外了（饭撒了一地，或者去上厕所去了），导致长时间没有释放资源（筷子）。但是 B 并不知道，于是傻傻的等待，用户就会认为 B 程序挂了。

android 有一个主线程，专门刷新 UI，如果你的程序阻塞主线程太久，就会弹出对话框提示

就是操作系统调用了你的程序等结果，你却迟迟不 return。命令行就不会未响应了。

我的理解是阻塞了或者死锁了，毕竟有的未响应能缓过来的

对操作系统来说就是事件处理程序没有在指定时间内完成。一般指的是 UI 主线程卡住导致 redraw 事件在数秒内无法完成。

我就说一个。plsql 天天未响应。

某个进程未响应，应该是指这个进程没有在指定时间内完成某个 task。
我觉得流程大概是这样的
1. 进程需要某个资源，发一条消息说我需要 xxx 资源，然后阻塞自己，把自己放到阻塞队列里，并设置一个 deadline
2. 如果 deadline 已经过了，该进程还没拿到自己需要的资源，然后它应该会重新回到就绪队列里，执行 deadline 过期的处理代码，我觉得这段代码就是拿来显示[未响应]这些东西的

阻塞队列里的进程应该也算是占用 CPU 的，因为 CPU 会定时 check 队列中的进程有没有过期。当然等你看到[未响应]三个字的时候，该进程应该已经回到就绪队列并执行 deadline 过期的代码了，就跟正常进程一样占用 CPU 时间的吧

其实不知道对不对

不处理用户操作了，就给你挂个未响应的牌子

其实 UI 上提示的未响应和操作系统进程的状态没有关系。UI 提示的那个未响应来源自窗口管理器，依据交互的窗口（主线程？）是否响应键盘\鼠标\触屏来判断。内核无俗谓未响应状态，如果按常人理解，都是资源问题，参考 1、2，3 楼。

1L 讲的比较到位, 更深一层的愿意, 阻塞的可能性比较大.
死锁的话, 一般除非是自己随便找的乱七八糟的程序, 否则发生的可能性应该不至于那么高: 实践当中碰到的"未响应"还是很频繁的.

UI 线程阻塞了，界面刷新不了，就这么简单

本质就是干其他的活去了，没空搭理你
通常 GUI 程序有一个线程专门负责刷新 UI 的，为了能及时响应用户的操作，你就不能在这个线程里面干一些耗时的事，否则长时间没有给用户反馈，就是假死现象了
CentOS 照样会出现的，任何系统都会出现，只要程序代码写得不合理

其实所有的 GUI 编程中，都存在类似 1L 所说的消息循环的概念。在 Win32 中，体现为
``` cpp
while((bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
```

GetMessage 由 Win32 的 Windows 的窗口子系统将外部事件转换为消息，发给获得焦点的进程。
进程在得到消息后，使用 TranslateMessage 翻译消息，最后调用 Dispatch 将消息发送给对应的窗口(Windows 里一个进程可以创建许多窗口)，在窗口中也有这样的消息循环，根据不同的消息执行不同的操作，这样就完成对外部事件的响应。
认为一个进程如果在 5 秒钟之内没有处理消息，Windows 就认为它失去响应了

> If a message has not been retrieved within 5 seconds, the DWM declares the window to be hung.

https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows
https://msdn.microsoft.com/en-us/library/windows/desktop/dd744765(v=vs.85).aspx

简单来说就是用户的一个操作（比如点击 输入 触摸等任何一个操作）都会触发一段代码，如果这段代码跑挂了就会挂了。
实际上是程序抛出异常。至于什么情况下这个异常严重到需要 crash，这就是 GUI 平台自己定义的了
比如说手机 APP，因为渲染有帧数限制，等待超过一定时间，系统会强制 crash 掉
比如桌面 exe，可能内存泄漏，可能死循环 死锁之类的，这也就是异常。但是要到了影响用户界面感知的情况下，才会被定义为「未响应」

程序未响应是 GUI 未响应，和死不死循环没有关系，操作系统也不知道，这是窗口管理器报的。
打个比方，如果你用 LINUX 下的文本编辑器，需要有 GUI，如 GEDIT。打开一个超级大的文件，基本上就会出现“程序未响应”状态。但未响应并不是说，程序“死”了，只是因为程序在读取文件上花费了大量的时间，导致 CPU 没有让渡给 UI 刷新。更没有时间响应 UI 事件。如果你等的时间足够长，最后程序还是会恢复正常的。
同样的，如果用 VIM 打开一个超大文件，也会使进程“卡住”。但你绝对看不到“程序未响应”的提示框，因为程序未响应是窗口管理器报的，没有 GUI 的程序自然不归窗口管理器管。

当然，也不排除一些程序确实因为实现原因，导致“未响应”

未响应只是表面上是程序和你没有正常交互，本质是由于某些原因导致原本可以正常响应外部输入的代码没能执行返回给你信息。
未响应的程序会不会占用 CPU 在于它为什么会未响应，如果它是在等待 io，或被挂起，它就不占用 CPU。如果是因为执行繁忙导致未响应，那就会占用 CPU。
最常见的非 UI 未响应也很常见，例如 ssh 连接网络不稳的服务器时，会因为网络等待导致未响应（输入一半命令卡死）。

楼上的全错了

判断程序未响应的不是操作系统，操作系统根本不关心进程 UI 是否响应，而是一个用户程序，这类程序我们叫做“窗口管理器”

进程本来就是死循环，操作系统本质也是死循环，这个没法检测，只不过死循环如果把 ui 线程卡了会让用户感觉卡了一样

@dosmlp 哭了，我们架构的死循环检测就被你说没了