Java多线程场景下inconsistent state（不一致状态）是什么？

你在查阅Thread.stop()弃用说明时碰到的这个术语，特指被监视器锁（monitor）保护的共享对象，在一次完整的原子修改操作尚未执行完毕时，被强行暴露给其他线程访问的半完成中间状态，和单线程场景下的对象非法状态不是同一个概念。

举个最直观的例子就能理解：

• 假设有个被synchronized锁保护的银行账户对象，要执行A向B转账100元的操作：正常逻辑是先从A账户扣减100元，再给B账户增加100元，两步全部执行完成后，两个账户的总金额平账，对象处于符合业务预期的一致状态。
• 如果扣减完A的余额、还没来得及给B加钱的执行中途，持有锁的线程被Thread.stop()强行终止：
  • 线程持有的所有锁会随着线程死亡、ThreadDeath异常向上传播的过程被全部释放，此时账户对象的总金额凭空少了100元，既不符合操作执行前的初始状态，也不符合操作完成后的预期状态，这就是inconsistent state
  • 后续其他线程拿到锁访问这个对象时，读到的就是这个半拉子的损坏状态，基于这个状态做的余额查询、转账、对账全都会出错，产生的问题可能是算错金额这种明显的异常，也可能是埋在流水里的隐性脏数据，极难排查。

这种状态的特殊危害在于，它和其他非受检异常不一样：ThreadDeath会直接静默杀死线程，不会给你任何明确的报错提示告诉你「刚才有个操作只执行了一半，对象已经损坏了」，这类问题可能在操作发生后几小时甚至几天，做日结对账、用户投诉余额异常的时候才会暴露，根本没法快速定位根因。

你之前检索到的单线程场景下的inconsistent state，一般指对象字段被设置了不符合规则的非法值（比如给年龄字段赋值为负数），属于参数校验、逻辑疏漏层面的问题；但多线程场景下的不一致状态，是合法的业务逻辑执行到一半被强行打断产生的中间态，哪怕你所有参数校验、业务代码写得完全正确，只要调用Thread.stop()强行终止线程，就有可能触发这类问题，没有提前防御的可能。

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