【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.0
【问题描述】
Oceanbase V4.0 相较于V3.*去掉了协程coroutine的使用，请问是出于哪些方面的考量？
(聚焦于ObThWorker这个类)
主要是稳定性考虑，C++协程模型的稳定性不及线程模型
2 个赞
ObThWorker这个类的大部分代码还在，但是协程相关的代码确实逐渐去掉了，可能还没有彻底删干净，后面我们会持续做这个工作。
我们确实在逐渐移除协程相关代码，主要是此前协程代码也只是在框架层面存在，并没有实际起作用（不是没有跑到），而移除的原因是，经过一系列的内部调研，我们确实打算不再使用协程方案。
相关讨论和调研过程比较长，后面有机会会单独出一篇文章，这里我只说部分主要结论。此前考虑协程的原因不仅是同步式多线程的编码风格确实非常复杂且容易出错，而且最主要的是线程的内存资源消耗也是非常大的。
经过一系列讨论，我们首先否定了纯异步式改造，callback陷阱和内存问题是一方面，纯异步对编码风格的巨大改变以及改造量也是我们难以接受的。
协程方面，OceanBase现有代码大量依赖线程局部变量，现有的协程库或者自己实现的协程库都无法满足这一需求，而协程局部变量的实现也比较复杂，对研发来说协程局部变量与线程局部变量的区分也容易混淆，就算这些解干净，也无法解决外部库中对线程局部变量的依赖，最典型的就是系统调用中的各种errno。另外，传统的协程方案也是无法实现抢占调度的，容易出现死锁问题。
但是，线程的内存占用却并不是难以优化的，经过一系列优化，我们大幅降低了线程对内存资源的消耗，其中不仅仅是线程局部变量，还包括线程局部的cache和一系列堆上的线程局部资源。
优化使得这个问题变得不是那么急迫了，因为线程不够可以加线程，虽然暂时不能自动加，但至少可以通过调整配置项cpu_quota_concurrency来解决大部分问题了（这个配置项在4.0也被放到了租户级）。长远来看，我们会通过轻量级线程这一方案来最终解决线程资源不足的问题。简单来说，就是在线程资源不足时，线程资源能够自动扩张（当然也包含后续的收缩）。
7 个赞
非常感谢您的解答