Kotlin实现可手动释放单例类的现有代码是否存在问题？

现有实现的合理性 #

你的设计思路完全匹配你提到的业务约束，整体方向是正确的：

• 用@Volatile修饰实例和计数器，保证多线程场景下的变量可见性
• 核心操作全程加synchronized锁，避免并发场景下的实例重复创建、计数错乱问题
• 引用计数的方案刚好适配「跨UI/Service共用单例、所有使用者退出后再释放资源」的需求，解决了你无法使用Hilt作用域、Kotlin object单例、AutoCloseable的问题

存在的问题和隐患 #

现有代码存在几个功能性bug和风险点：

• 计数操作顺序错误：get方法中先对计数器+1，再判断实例是否存在，若AudioRepo构造函数抛出异常，会出现计数器已经+1但实例创建失败的情况，最终计数器永远无法归零，后续也无法再创建新实例
• 空指针风险：release方法中用INSTANCE!!强制取值，若从未调用过get就直接调用release，计数器减到0后会触发空指针崩溃
• 容错性差：漏调用一次release就会导致实例永远无法释放，资源泄漏风险高，尤其在Compose重组、页面异常退出等场景很容易漏调用
• 异常逻辑不合理：多余的IllegalStateException抛出会把使用者的错误操作转化为应用崩溃，生产环境风险高

优化后的代码实现 #

companion object {
    @Volatile
    private var INSTANCE: AudioRepo? = null

    @Volatile
    private var counter: Int = 0

    @JvmStatic
    fun release() {
        synchronized(this) {
            if (counter <= 0) {
                // 生产环境建议打警告日志即可，不要抛出异常崩溃
                Log.w("AudioRepo", "尝试释放不存在的AudioRepo实例，已忽略操作")
                return
            }
            counter--
            if (counter == 0) {
                // 用安全调用替代!!避免空指针
                INSTANCE?.destroy()
                INSTANCE = null
            }
        }
    }

    @JvmStatic
    fun get(context: Context): AudioRepo {
        synchronized(this) {
            // 先完成实例创建，再修改计数器，避免实例创建失败导致计数异常
            val instance = INSTANCE ?: run {
                AudioRepo(context.applicationContext as Application).also {
                    INSTANCE = it
                }
            }
            counter++
            return instance
        }
    }
}

使用建议 #

• Compose场景下配合DisposableEffect自动调用release，避免手动漏写：

  DisposableEffect(Unit) {
      val audioRepo = AudioRepo.get(context)
      onDispose {
          AudioRepo.release()
      }
  }
  

• Service场景下在onDestroy生命周期中固定调用release
• Debug包可加检测逻辑，应用退到后台时若计数器不为0则输出日志，方便定位漏调用的场景

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