Clojure中使用reset!与重新def修改atom绑定变量有何区别？

根据Clojure官方文档，reset!的用法说明如下：

不考虑atom的当前值，直接将atom的值设置为新值，返回该新值。

基础使用示例：

user> (def my-test (atom 666))
#'user/my-test
user> my-test
#<Atom@66d7a880: 666>
user> @my-test
666
user> (reset! my-test 77)
77
user> my-test
#<Atom@66d7a880: 77>
user> @my-test
77

很多初学者在REPL中尝试重新执行def创建同名atom时，会发现表面输出和reset!效果类似，操作示例如下：

user> (def my-test (atom 666))
#'user/my-test
user> my-test
#<Atom@66d7a880: 666>
user> @my-test
666
user> (reset! my-test 77)
77
user> my-test
#<Atom@66d7a880: 77>
user> @my-test
77

;;;; 通过def将其改回初始值
user> (def my-test (atom 666))
#'user/my-test
user> @my-test
666
user> my-test
#<Atom@7ce4f432: 666>

仅从REPL的直接输出很难第一时间发现二者区别，但二者本质完全不同，核心差异可以总结为三点：

• 操作的目标完全不同：reset!是修改已经存在的同一个atom实例内部存储的值，执行前后atom的内存地址不会变（比如上面示例中reset!前后地址始终是66d7a880）；而重新执行def是创建了一个全新的atom实例，再把my-test这个全局Var的绑定指向新实例，旧的atom实例如果没有其他引用会被垃圾回收，示例里重def后的atom地址变成了7ce4f432，已经和之前的对象没有任何关系。
• 线程安全与状态一致性表现天差地别：reset!是Clojure为atom设计的原子性修改API，天生线程安全，所有持有这个atom引用的代码、线程都能同步看到最新值；重def只是修改Var的根绑定，根本不是为并发状态同步设计的——只要有任何代码提前保存了旧atom的引用（比如把atom作为参数传给其他函数、存入其他状态容器、被其他线程持有），这些位置永远看不到新def的atom的值，会直接出现状态不一致的隐蔽bug。
• 设计定位完全不同：def的作用是在命名空间顶层定义Var，只应该在命名空间加载、REPL临时调试定义变量时使用，生产代码中绝对不能把重def当做修改状态的手段；reset!才是atom提供的标准状态更新接口，专门用来做可控的同步状态修改。

可以用一个简单的示例直观展示这个差异：

;; 初始定义atom，同时把这个atom实例保存到另一个变量中（模拟实际开发中传递引用的场景）
user> (def my-atom (atom 0))
#'user/my-atom
user> (def hold-old-atom my-atom)
#'user/hold-old-atom

;; 用reset!修改atom值
user> (reset! my-atom 100)
100
user> @hold-old-atom ;; 持有的是同一个实例，能正常拿到更新后的值
100

;; 重新def同名的新atom
user> (def my-atom (atom 999))
#'user/my-atom
user> @my-atom ;; 直接访问Var能拿到新atom的值
999
user> @hold-old-atom ;; 之前保存的引用还是指向旧实例，值停在100，完全感知不到变化
100

实际项目中atom的引用会在大量代码间传递，不可能所有位置都直接通过全局Var名访问atom，这种情况下重def相当于直接制造了多份不一致的状态，排查问题的成本极高。除此之外，重def还会重置Var的元数据，如果Var有编译期内联的常量标记，甚至会出现部分代码拿到新值、部分代码用旧内联值的诡异问题，完全不可控。
简单说：只要你的需求是修改一个已经存在的atom的内部状态，永远用reset!、swap!这类atom专属的API，def只用来做初次的变量定义，不要拿来当状态修改工具。

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