JDK 26.0.2 写入中断后 checkError 为什么变成 true：PrintStream 与 PrintWriter 新语义

升级到 JDK 26.0.2 后，一段依赖 PrintStream.checkError() 或 PrintWriter.checkError() 的代码可能开始更早发现失败。原因不是正常写入语义改变，而是底层自定义输出流抛出 InterruptedIOException 时，包装器现在既设置线程中断状态，也设置自身错误标记；随后调用 checkError() 会返回 true。

旧语义和新语义差在哪

问题只出现在一个明确边界：PrintStream 或 PrintWriter 包装了自定义输出流，而该输出流的 write 抛出 InterruptedIOException。过去，当前线程会留下线程中断标记，但包装器的错误标记没有同步置位，于是 checkError() 可能仍是 false。

JDK 26.0.2 把两个可观察状态对齐。InterruptedIOException 仍然代表写入被中断，线程中断标记继续保留；同时，PrintStream 与 PrintWriter 会设置错误标记，checkError() 因此能报告失败。

最小代码怎样核对新行为

final class InterruptingOutput extends OutputStream {
    @Override
    public void write(int value) throws IOException {
        throw new InterruptedIOException("write interrupted");
    }
}

var printer = new PrintStream(
    new InterruptingOutput(), true, StandardCharsets.UTF_8
);
printer.print("order-42");

boolean failed = printer.checkError();
boolean interrupted = Thread.currentThread().isInterrupted();

在新语义下，failed 与 interrupted 都应反映异常。示例只用于说明状态边界；真实项目还要决定是否关闭包装器、记录失败位置，以及上层任务能否安全重试。

把 checkError 放进真正的失败分支

更稳妥的结构是让业务写入只接触 PrintStream，写完立即读取 checkError()，并同时保留线程中断标记。两项任一异常都进入失败分支，再由失败分支选择重试策略和日志记录。不要在底层随手清除中断状态，否则上层任务调度器可能失去取消信号。

这里的重试策略必须由业务幂等性决定。例如生成报表文件可写入新临时文件后重试；向不可重复消费的外部目标输出时，直接重试可能造成重复数据。日志记录至少保留目标标识、写入阶段和中断状态，避免只留下一个布尔值。

升级时重点检查哪些代码

• 搜索自定义 OutputStream、PrintStream 和 PrintWriter 的组合使用。
• 检查是否依赖“InterruptedIOException 后 checkError() 仍为 false”的旧行为。
• 确认错误分支不会重复提交不可幂等的数据，也不会吞掉线程中断状态。
• 针对网络输出、报表导出和任务取消各保留一个回归用例。

普通文件写入没有抛出 InterruptedIOException 时，不会因为这项修正自动变成失败。升级风险主要集中在自定义输出流、远程输出适配器以及主动响应线程中断的实现。

常见问题

checkError() 返回 true 后还能继续写吗？

API 允许继续调用，但错误标记不会因此自动恢复。更可靠的做法是停止使用当前包装器，处理底层输出资源，再按业务幂等规则决定是否重建和重试。

可以用 Thread.interrupted() 检查状态吗？

要谨慎。它会读取并清除当前线程的中断状态；如果这里只想观察，优先使用 Thread.currentThread().isInterrupted()，把是否清除交给明确的上层策略。