在Kotlin中，是否存在使用线程而非协程的合理场景？

你已经抓准了协程的核心优势——轻量、低资源消耗，适合高并发场景，但确实存在一些场景下直接用线程更合适，甚至是必须的：

必须使用线程的场景 #

• 依赖线程绑定的旧代码/原生库：有些老旧的Java库、JNI实现的功能，设计时就强依赖Thread实例或者ThreadLocal存储的状态，而且无法适配协程的上下文传递逻辑。强行用协程包裹这类代码，要么会引入复杂的适配层，要么会导致状态错乱，直接用线程反而更简单可靠。
• 需要底层线程控制的操作：如果需要修改线程优先级、设置CPU亲和性（绑定到特定CPU核心）、获取线程ID做系统级追踪这类操作，只能通过Thread类的原生API实现，协程本身没有提供对应的接口，这种场景下必须直接操作线程。
• 独占CPU的长时间计算任务：比如大型数值计算、视频编码这类持续占用100%CPU的任务，协程的协作式调度可能会让同一线程池里的其他协程得不到执行机会。而直接分配一个独立线程交给操作系统调度，能更高效地利用CPU资源，也不需要协程调度的额外开销。

线程性能更优的场景 #

• 纯CPU密集且无挂点的超长任务：协程调度虽然开销极小，但如果任务全程不需要挂起、一直占用CPU，那么直接用线程可以完全避免这部分调度开销，性能会略胜一筹。不过这种场景比较少见，大多数CPU密集任务都可以拆分成小块让协程调度，但如果是无法拆分的单一大任务，线程更高效。
• 极致低延迟要求的场景：比如高频交易、实时信号处理这类对延迟敏感到纳秒级的场景，协程的切换开销哪怕再小，也可能成为瓶颈。直接用线程执行无挂起的任务，能达到最低的延迟。

总结 #

协程是并发编程的首选，但不是银弹：

• 当你需要处理IO密集、高并发、频繁挂起的任务时，协程的优势拉满；
• 当遇到上述依赖线程绑定的代码、需要底层线程控制、或者极致性能要求的场景时，直接用线程是更合理的选择。

内容的提问来源于stack exchange，提问作者J-bob