IllegalStateException 表示对象当前状态不支持所调用方法，如对已关闭Connection再调用close()，而非参数错误；需在调用前主动校验状态，避免盲目捕获掩盖问题。
IllegalStateException 是状态错，不是参数错
它表示对象当前所处的状态，不支持你正在调用的方法——比如对一个已关闭的 Connection 再调用 close()，或对一个已完成的 CompletableFuture 调用 complete()。这不是传参不对（那是 IllegalArgumentException），而是“这东西现在不能干这事”。
常见错误现象包括：
java.lang.IllegalStateException: zip file closedjava.lang.IllegalStateException: Cannot call sendError() after the response has been committedjava.lang.IllegalStateException: FragmentManager is already executing transactions
这类异常通常出现在资源生命周期管理混乱、多线程误操作、或框架回调时机误判时。
排查重点：看堆栈里谁在调用、谁在管理状态
别急着改代码，先盯住异常堆栈最上面几行：是哪个类的哪个方法抛的？它的状态变量（比如 closed、isDone、mState）有没有被显式维护？很多框架（如 Spring、Android Support Library）会把状态检查写在 public 方法入口，但状态更新可能分散在 private 回调或异步路径中。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 搜索该类源码里所有对
state、closed、isStarted等字段的赋值点，确认是否遗漏了某条路径 - 检查是否在多线程环境下共享了本应单线程使用的对象（如
SimpleDateFormat、Scanner） - 如果是 Android 中的
Fragment或FragmentManager相关异常，优先检查是否在onDestroyView()后还触发了 UI 更新 - 用 IDE 的 “Find Usages” 查
setState(...)或类似方法，比盲目加 log 更快定位状态变更源头
try-catch 不是解法，状态守门才是关键
捕获 IllegalStateException 并吞掉，大概率只是掩盖问题。真正要做的，是在调用前主动判断状态是否允许——尤其在资源释放、状态切换、异步回调等敏感场景。
示例对比：
if (!connection.isClosed()) {
connection.close(); // 安全
}
vs 错误写法：
try {
connection.close(); // 可能抛 IllegalStateException
} catch (IllegalStateException ignored) {} // 忽略后连接没关干净
注意点：
- 有些类不提供状态查询方法（如老版本
ZipFile），就得靠自己维护标志位或改用try-with-resources - 并发场景下，即使加了 if 判断，也可能因竞态条件失效，此时需配合
synchronized或原子状态机（如AtomicBoolean.compareAndSet） - Spring 的
ApplicationContext关闭后调用getBean()也会抛此异常，说明上下文已不可用，该停服务就停，不该硬扛
容易被忽略的“隐式状态变更”场景
很多 IllegalStateException 来自你以为“没动它”，其实框架或库悄悄改了状态。比如：
-
HttpServletResponse在第一次写响应体后自动 commit，之后再调用sendRedirect()就会崩 -
RecyclerView.Adapter在notifyDataSetChanged()后若还在主线程外修改数据列表，后续onBindViewHolder()可能因内部状态不一致而炸 - JDK 的
Stream一旦被消费（如forEach），再次调用count()就会抛此异常——它不报UnsupportedOperationException，因为这是流的“已终结”状态，不是能力缺失
这些地方没有明显“开关”变量，状态藏在实现细节里。遇到这类异常，翻对应类的 JavaDoc 比看源码更快，关键词搜 “state”, “after”, “once”, “already”。
