# 1. BufferedInputStream/BufferedReader 的缓冲机制与 mark/reset 语义的边界限制 A 缓冲减少 I/O 调用，mark/reset 受 readlimit 限制，超过则 reset 失效抛异常 ✓ 正确答案 B readlimit 无意义 C mark 后无限 reset D reset 总是成功
# 2. ByteArrayOutputStream 与 PipedInputStream/PipedOutputStream 的典型用途与线程死锁坑点 A Piped 流无死锁风险 B ByteArrayOutputStream 用于磁盘 C Piped 流无需连接 D ByteArrayOutputStream 内存累积输出，Piped 流线程间传输，死锁坑点是缓冲满阻塞与线程依赖 ✓ 正确答案
# 3. Java I/O 装饰器模式，BufferedInputStream/DataInputStream/GZIPInputStream 的组合原理 A 装饰器模式只用于缓冲 B 功能不可叠加 C 包装顺序无关 D 通过逐层包装叠加缓冲/解压/类型读取功能，顺序影响正确性 ✓ 正确答案
# 4. 在 Spring Boot 4.0 启动时 file.encoding 默认值与 Docker 镜像 LANG 环境变量的优先级如何 A LANG 优先于默认 UTF-8 B 默认编码依赖 LANG C 显式参数无效 D 显式 -Dfile.encoding 优先，JDK 18+ 默认 UTF-8，LANG 不再影响默认编码 ✓ 正确答案
# 5. ObjectInputStream 读取对象图时循环引用如何通过句柄表识别，与普通字节流的顺序读取有何差异 A 循环引用无法识别 B ObjectInputStream 用句柄表识别循环引用并保持引用关系，普通字节流无此概念 ✓ 正确答案 C 普通字节流也维护句柄表 D 句柄表只用于性能
# 6. Reader 与 InputStream 的 read() 都返回 int，两者的取值范围与 EOF 语义有何不同 A 两者取值范围相同 B Reader 返回字节 C InputStream 返回字节 0-255，Reader 返回字符 0-65535，EOF 都返回 -1 ✓ 正确答案 D EOF 语义不同
# 7. MappedByteBuffer 与内存映射的性能价值 A 内存映射增加系统调用 B 内存映射减少系统调用、利用页缓存，适合大文件与顺序写场景 ✓ 正确答案 C 内存映射只适合小文件 D 内存映射无性能优势
# 8. 代理对被切在两个 ByteBuffer 或字符块之间时，增量解码器应如何保存并恢复未完成状态 A 分割时直接丢弃 B 无需处理分割 C 多字节/代理对被分割时，增量解码器需保存未完成状态（CharsetDecoder 内部缓存），下次恢复 ✓ 正确答案 D 解码器不能保存状态
# 9. BufferedOutputStream 与 BufferedWriter 的缓冲刷新时机，flush 与 close 在异常路径下的资源释放顺序 A close 不刷新缓冲 B 缓冲满/flush/close 触发刷新，异常路径用 finally 保证先 flush 再关闭底层流 ✓ 正确答案 C flush 总是在 close 之后 D 异常时无需关闭流
# 10. DataOutputStream 的 writeUTF 与 writeChars 在长度前缀和字节序上的差异，跨语言读取时为何容易踩坑 A 两者完全相同 B writeUTF 无长度前缀 C writeChars 无字节序问题 D writeUTF 带长度前缀+Modified UTF-8，writeChars 固定 2 字节无前缀，跨语言解析 Modified UTF-8/字节序易踩坑 ✓ 正确答案
# 11. FilterInputStream/FilterOutputStream 的模板方法模式与子类扩展点 A 子类无需覆写方法 B Filter 流是装饰器基类，子类覆写 read/write 等方法扩展功能，体现模板方法模式 ✓ 正确答案 C Filter 流不能装饰 D 扩展点只有 close
# 12. InputStreamReader 的缓冲大小与字符转换开销如何权衡，逐字符读取为何性能差 A 逐字符读取性能最好 B 缓冲大小无关紧要 C 缓冲大小影响 I/O 与解码次数，逐字符 read() 频繁调用开销大，应用缓冲批量读取 ✓ 正确答案 D 缓冲增加系统调用
# 13. PrintStream/PrintWriter 的自动 flush 与错误吞没（checkError）在生产日志落盘中的坑 A 不自动 flush 丢日志、错误吞没（checkError 不检查则静默），生产应使用日志框架 ✓ 正确答案 B 错误会直接抛出 C PrintStream 总是 flush D 日志框架无必要
# 14. OutputStreamWriter 编码错误时的默认行为（替换/报错），与 CharsetEncoder 的 REPORT 策略如何对接 A OutputStreamWriter 默认 REPORT 报错 B 编码错误总会抛异常 C OutputStreamWriter 默认 REPLACE 替换产生乱码，要报错需自定义 CharsetEncoder 设 REPORT ✓ 正确答案 D 无法对接 REPORT 策略
# 15. GZIPInputStream 与 BufferedInputStream 的叠加顺序为何影响解压性能，包装顺序错误会带来什么后果 A 缓冲应在上层 B 顺序不影响性能 C 缓冲应在底层（GZIPInputStream(buffered)），顺序颠倒导致底层 I/O 频繁、解压性能下降 ✓ 正确答案 D 顺序颠倒会损坏数据
# 16. 自定义 FilterInputStream 子类需要重写哪些方法才能保持装饰器链的语义完整性，常见错误委托有哪些 A 只需重写 read() B close 不处理不会泄漏 C 无需委托底层 D 需完整重写 read/skip/available/close 等并正确委托底层，避免部分方法绕过自定义逻辑 ✓ 正确答案
# 17. RandomAccessFile 的 seek 与 FileChannel 的 position 在并发读写时的线程安全差异 A 两者都有 position 竞争，并发读写需独立通道或 absolute position 重载，默认非线程安全 ✓ 正确答案 B RandomAccessFile 线程安全 C 两者都线程安全 D FileChannel 并发读写无竞争
# 18. StreamTokenizer 的语法解析局限，为什么现代协议解析改用 PushbackInputStream 手动分词 A StreamTokenizer 支持复杂语法 B PushbackInputStream 不支持回退 C StreamTokenizer 分词规则简单，现代协议用 PushbackInputStream 的 unread 回退实现精确手动分词 ✓ 正确答案 D 现代协议解析用 StreamTokenizer 最佳
# 19. ByteArrayInputStream 与 ByteArrayOutputStream 的内存占用，大对象流式处理为何应改用文件流或管道 A ByteArray 流不占内存 B ByteArray 流数据全量驻留内存，大对象应改用文件流/管道流式处理避免 OOM ✓ 正确答案 C 大对象用 ByteArray 流最优 D 文件流不适合流式
# 20. ObjectInputStream/ObjectOutputStream 的协议 A 协议无头信息 B 协议是固定长度 C 协议不包含类描述 D 协议以魔法头开头，含类描述、对象数据、句柄，自描述可重建对象图 ✓ 正确答案
# 21. ObjectStreamClass 与字段演进 A 字段变化导致反序列化总失败 B 新增字段无默认值 C ObjectStreamClass 描述序列化类，字段演进新增用默认值、删除忽略，serialVersionUID 控制兼容 ✓ 正确答案 D ObjectStreamClass 与字段无关
# 22. PushbackInputStream 的 unread 回退在协议解析（如 HTTP 头边界检测）中的应用 A unread 放回字节实现前瞻解析，用于检测协议边界（如 HTTP 头 \r\n\r\n） ✓ 正确答案 B 协议解析无需回退 C unread 只能用于字符流 D unread 会丢弃数据
# 23. SequenceInputStream 的流合并与多个数据源顺序读取的工程场景 A 流合并会并行读取 B SequenceInputStream 只读一个流 C SequenceInputStream 按顺序合并多流，用于多文件/多源顺序读取作为单一流处理 ✓ 正确答案 D SequenceInputStream 用于写入
# 24. StringReader/StringWriter 作为内存中字符流与 StringBuilder 的取舍 A StringBuilder 提供流式 API B StringReader 用于磁盘 C StringReader/Writer 提供流式 API 便于流式集成，StringBuilder 直接拼接更高效，按需选择 ✓ 正确答案 D 两者完全相同
# 25. readResolve/writeReplace 的单例保护 A readResolve 会创建新实例 B writeReplace 在反序列化后调用 C readResolve 反序列化后返回替换对象保护单例，writeReplace 序列化前替换 ✓ 正确答案 D 单例无法用序列化保护
# 26. transient 字段与 writeObject/readObject 自定义 A transient 字段总会序列化 B 自定义 readObject 无法读 transient C transient 只影响性能 D transient 字段不参与默认序列化，自定义 writeObject/readObject 可序列化 transient 或控制逻辑 ✓ 正确答案
# 27. try-with-resources 与 Closeable/AutoCloseable 的资源关闭顺序（声明逆序）与 suppressed 异常 A 资源按声明顺序关闭 B 资源按声明逆序关闭，关闭异常作为 suppressed 附加，不覆盖主体异常 ✓ 正确答案 C 关闭异常覆盖主体异常 D 无 suppressed 概念
# 28. Reader/Writer 与 InputStream/OutputStream 的 available() 语义差异，为什么字符流没有可靠的 available A 字符流有可靠 available B 字节流 available 可估计可读字节，字符流因解码与缓冲无法可靠报告可读字符数 ✓ 正确答案 C Reader 与 InputStream 的 available 相同 D 字符流没有解码问题
# 29. 序列化流中 writeUTF 的 Modified UTF-8 与标准 UTF-8 的差异，超长字符串为何容易踩长度上限 A Modified UTF-8 与标准 UTF-8 完全相同 B Modified UTF-8 对 0 字节/代理对编码不同，writeUTF 用 2 字节长度上限按字节数，超长字符串抛异常 ✓ 正确答案 C 长度上限按字符数 D 超长字符串不会抛异常
# 30. LineNumberInputStream 的已弃用原因与 LineNumberReader 的替代方案 A LineNumberInputStream 仍推荐使用 B LineNumberReader 是字节流 C 行号与字符集无关 D LineNumberInputStream 是字节流不适合行号处理，LineNumberReader 字符流正确处理换行与编码 ✓ 正确答案
# 31. 传统文件 I/O 的 read/write 路径与缓冲，为什么 FileInputStream 逐字节读性能远低于带缓冲读取 A 逐字节读更高效 B 逐字节 read() 每次触发一次系统调用，开销大，缓冲批量读减少系统调用提升性能 ✓ 正确答案 C 缓冲读增加系统调用 D 性能差异与系统调用无关
# 32. FileInputStream/FileOutputStream 的 finalize 已弃用与显式 close 的必要性 A finalize 可靠释放资源 B finalize 执行时机不确定已弃用，必须显式 close（try-with-resources）避免 fd 泄漏 ✓ 正确答案 C 无需显式 close D fd 资源无限
