加载失败
讨论源自一篇关于“Async and Finaliser Deadlocks”的文章，核心在于对象终结器（finalizer）与异步/并发代码在资源释放和锁管理上的不确定交互。评论引用了多种语言和运行时差异来说明问题：Rust 的 futures 模型带来 futurelock 与 cancellation safety 的挑战，Tokio 的 select! 容易暴露取消语义风险；Java 因不可预测的 finalizer 行为转向 AutoCloseable 和 Cleaner 等显式清理方案；Python 的生成器和 PyPy/CPython 在对象销毁时机上的差异被用作对比。争论集中在问题是否为语言/runtime 特性所致、还是工程实践不足，并讨论了若干实际规避策略。
评论普遍认为 finalizer（对象终结器，垃圾回收时的清理回调）在时机和可见性上不可靠，任何“有用”的 finalizer 都会触及全局共享状态，从而把不可预测的锁操作引入程序执行。因为 finalizer 可能在 GC、线程或不同运行时实现（如 PyPy 与 CPython）中在不同时间触发，它会在意外时刻获取或释放锁，导致死锁或竞态。Java 因此弃用 finalizers，转向显示同步清理（AutoCloseable）或在独立机制/线程中异步清理（Cleaner），评论把把关键资源释放交给 finalizer 形容为“送死”。
部分评论把问题归到 Rust 特有的“futurelock”现象：当 futures 在被取消或 Drop 时仍持有锁，资源释放顺序与取消语义不匹配会导致死锁。评论指出这不是传统 finalizer 的时机问题，而是与 Rust futures 的执行模型和 cancellation safety（取消安全）有关；Rust 的 futures 架构不能简单地用 Python 示例来类比。还有人警告 tokio::select!（Rust Tokio 的多路选择宏）在不了解取消/Drop 行为时容易制造死锁或奇怪的性能问题，强调要谨慎使用该抽象。
有评论反驳示例并非固有的异步问题，而是语法糖或同步删除在运行时执行的结果：删除动作本质上是同步代码在某个时刻运行。Python 的行为差异被反复提及：PyPy 的垃圾回收时机可能与 CPython 不同，短程序中 PyPy 可能根本不会调用 finalizer，说明终结器行为依赖运行时实现。一个具体的 Python 生成器示例展示了 generator 在 yield 点之后仍持有 mutex，除非显式 next 或对象被销毁，否则锁不会释放，这使得从代码中直接看出问题变得困难。
多位评论给出工程层面的规避办法：将长事务拆成有限状态机，仅在同步阶段短时间持锁；将并行计算设计成纯函数以避免写锁，并在需要时放宽隔离级别或采用乐观并发控制。还有建议采用单线程执行器或多进程模式从根本上减少线程同步问题，或在启动并发任务后使用节流/限流并按序 await 结果以有序应用更新。总体思路是把需要跨任务的全局状态更新序列化或可重入化，从而减少 finalizer/取消时引发的死锁面。
finalizer（终结器）: 在垃圾回收或对象销毁时运行的清理回调；其触发时机随运行时而异，若触及全局状态或锁会引入不可预测的竞态或死锁风险。
futurelock: 社区用语，描述 Rust async/future 在被取消或 Drop 时仍然持有锁，从而在资源释放与取消语义上引发死锁或一致性问题；与传统 finalizer 问题不同，核心是取消语义。
cancellation safety（取消安全）: 指在取消异步任务或 Drop futures 时，系统能保持一致状态且不会遗留锁或资源的属性；需要明确定义中断点的清理与资源释放顺序。