一、一个看起来没问题的实现

假设我们有这样一个需求：

• Retrofit 初始化成本较高
• BaseUrl 需要远程获取
• 希望懒加载
• 多个协程并发访问时只初始化一次

很多人第一反应会这样写：

object RetrofitClient {
private var retrofit: Retrofit?话说回来，= null
fun getRetrofit: Retrofit {
return retrofit?: synchronized {
retrofit?: buildRetrofit.also {
retrofit = it
}
}
}
private fun buildRetrofit: Retrofit {
val baseUrl = runBlocking {
ConfigRepository.fetchRemoteConfig
}
return Retrofit.Builder
.baseUrl
.addConverterFactory)
.build
}
}

其中 fetchRemoteConfig 是挂起函数

代码这方面，

• 能编译
• 能运行
• 看起来还是标准 DCL

但问题很大！

二、问题不在 DCL，而在 synchronized

很多人误以为这方面。

协程 + synchronized = 安全

：协程环境下 synchronized 保护的是线程不是协程！更严重的是 runBlocking 直接把原本应该挂起的异步逻辑变成了同步阻塞。

此时这方面，协程优势全部消失 等待网络期间线程被锁住无法释放 如果发生在主线程会导致ANR 这完全退化成传统Java并发模型。

三、协程版 DCL 应该长什么样？正确思路是替换线程锁为 Mutex，将阻塞等待改为 suspend 挂起。

object RetrofitClient {
@Volatile
private var retrofit: Retrofit?= null
private val mutex = Mutex
suspend fun getRetrofit: Retrofit {
return retrofit?: mutex.withLock {
retrofit?: buildRetrofit.also {
retrofit = it
}
}
}
private suspend fun buildRetrofit: Retrofit {
val baseUrl = ConfigRepository.fetchRemoteConfig
return Retrof...


HTML排版说明以上内容已按HTML格式输出。包含以下特点：
1. 使用

和

标签划分章节结构
2. 强调使用者痛点部分使用加粗标记
3. 代码块使用
+标签语法高亮
4. 特殊提示使用


5. 列表项用

/

/


6. 关键术语使用或强调


建议配合以下CSS使得痛点更显眼：
css
.pain-point,strong.pain-point { background-color: #ffebee;color: #d81b60;padding: 0.1em 0.3em;border-radius: 3px;}