题目

下列关于线程的描述中，错误的是（ ）。

错因

A

误以为"内核级线程"和"用户级线程"是两种平行的实现方式、调度都由 OS 做。这反而是对的——KLT 的本质特征就是 OS 知道它的存在并负责调度。题问"错误的"，A 描述的是 KLT 的标准定义，看走眼"错误"两个字就误选了。

C

承认"用户级线程切换不进内核态"，又被本题反向措辞"错误的"绕住，把这条对的当成错的勾选。ULT 切换全在用户态线程库里完成（保存栈、改 PC、恢复另一线程的栈即可），无需陷入内核、不刷 TLB、不切地址空间——比 KLT 切换快得多是公认事实。

D

也是反向措辞陷阱：选项陈述本身正确（ULT 由用户态库实现，跟 OS 是否支持 KLT 无关），但因为题问"错误的"看反了。早期 UNIX、JVM 早期的绿色线程都属于"OS 完全不知线程"也照样能跑用户级线程，正是这条性质的体现。

总解析

题问"错误"，先把四个选项按线程归属梳理一遍：

性质	用户级线程 ULT	内核级线程 KLT
谁感知它的存在	仅用户态线程库	OS 内核
TCB 由谁建	线程库（不是 OS）	OS
调度由谁做	线程库（OS 看到的是整个进程）	OS（A 描述的就是这条）
切换开销	不进内核，快（C 描述的就是这条）	进内核态、刷上下文，慢
对 OS 的依赖	不依赖 OS 是否支持 KLT（D 就是这条）	依赖 OS 提供 KLT 抽象

逐条核对：

• A：内核级线程由 OS 调度 → 正确
• B：OS 为每个用户级线程建 TCB → 错误 ❌
  ULT 的 TCB（栈、寄存器、状态）由线程库在用户态自行维护，OS 根本看不到一个进程里有几个 ULT。这正是 ULT 切换不进内核、效率高的根因，也是 ULT 能跑在不支持 KLT 的 OS 上的根因。如果 OS 反过来要为每个 ULT 建一份 TCB，那它就已经是 KLT 了。
• C：ULT 切换比 KLT 切换效率高 → 正确（不进内核）
• D：ULT 可在不支持 KLT 的 OS 上实现 → 正确（仅靠用户态库）

题问"错误的"，B 是被否定的命题。

最终答案是 B。