题目

下列选项中，可能将进程唤醒的事件是（ ）。

Ⅰ. I/O 结束 Ⅱ. 某进程退出临界区 Ⅲ. 当前进程的时间片用完

错因

A

承认 I/O 结束会唤醒等 I/O 的进程，却没意识到 Ⅱ 也是同一类事件。可能把"退出临界区"误以为只是"释放锁"这件事——但锁释放的瞬间，等这把锁的进程就在等待队列里挂着，OS 必须把其中一个唤醒（V 操作里的 wakeup），它才有机会再去抢——这跟 I/O 结束唤醒等 I/O 的进程在状态转换上完全等价。

B

把"时间片用完"误识别成了唤醒事件。但时间片用完触发的是当前正在运行的进程让出 CPU 进入就绪态——它从来就没"睡着"过，谈不上"唤醒"（唤醒特指阻塞 → 就绪）。这是把"调度切换"和"唤醒"混为一谈。

D

把所有"会引起调度的事件"都当成唤醒了。Ⅲ 时间片用完确实会触发调度，但被切走的进程是从运行态进入就绪态，方向跟唤醒（阻塞 → 就绪）完全相反。两件事都让别的进程得到 CPU，但只有 Ⅰ Ⅱ 是把睡着的进程拉醒。

总解析

"唤醒"在状态转换里有严格定义：阻塞态 → 就绪态。需要先有进程在等某个事件而处于阻塞，事件发生时才有"被唤醒"一说。

事件	谁因此发生状态变化	状态变化方向	是否唤醒？
Ⅰ I/O 结束	等待该 I/O 的进程	阻塞 → 就绪	是 ✓
Ⅱ 某进程退出临界区	等该临界资源（在信号量阻塞队列里）的进程	阻塞 → 就绪	是 ✓
Ⅲ 当前进程时间片用完	当前正运行的进程自己	运行 → 就绪	否（被剥夺，不是被唤醒）

区分钥匙：进程之前是不是因为"等什么"才睡着的——是的话事件发生才叫唤醒；如果它本来就在跑，被 OS 切走只是调度，不算唤醒。

仅 Ⅰ Ⅱ 触发唤醒。

最终答案是 C。