如何将带状态变量的可取消Thread类替换为Kotlin协程实现

完全可以用Kotlin协程实现需求，且可以完整保留内部封装特性，相比原生线程版本资源占用更低、扩展性更强。

实现代码 #

首先补全SomeObject的参考定义（方便代码可运行）：

class SomeObject {
    var keepGoing = true
    var value = 0
}

协程版本的MyCancellable实现：

import kotlinx.coroutines.CoroutineScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.Job
import kotlinx.coroutines.launch
import kotlinx.coroutines.yield

class MyCancellable {
    // 完全保留原有的内部封装属性
    val someObject = SomeObject()
    // 内部私有协程作用域，外部不可访问，保证封装性
    private val scope = CoroutineScope(Dispatchers.Default + Job())
    private var runningJob: Job? = null

    // 对应原Thread类的start()方法，调用后启动任务
    fun start() {
        runningJob = scope.launch {
            while (someObject.keepGoing) {
                someObject.value++
                // 纯计算场景建议加yield，主动让出调度权，同时支持响应协程取消
                yield()
            }
        }
    }

    // 完全保留原有的cancel逻辑，同时补充协程取消兜底
    fun cancel() {
        someObject.keepGoing = false
        runningJob?.cancel()
    }
}

方案说明 #

• 封装性完全符合要求：someObject、协程作用域都封装在类内部，外部调用方式和原生线程版本几乎一致，不需要感知内部的协程实现细节。
• 资源效率更高：原生线程是OS级资源，单个线程默认占几MB栈空间，创建销毁开销大；协程是用户态调度的轻量任务，即使同时运行上千个也不会有明显资源压力。
• 扩展性更强：如果后续需要在循环中增加挂起操作（如延时、网络/IO请求），协程版本不需要修改整体结构，直接调用挂起函数即可，不需要处理线程阻塞的额外问题。

关于原线程版本的适用性 #

如果你的业务场景中这个类只会实例化极少数对象，且逻辑已经完全稳定没有后续扩展需求，原线程版本也完全可以正常使用，不存在明显缺陷。只是协程版本的适配场景更广，后续迭代成本更低。

内容的提问来源于stack exchange，提问作者salyela