在Java中Reader和Writer有什么不同_Java字符流使用解析

Reader专用于读、Writer专用于写，因接口契约无对应方法且IO分层隔离，故不可互换；FileRe

ader/FileWriter默认编码依赖系统，易致乱码，须用InputStreamReader/OutputStreamWriter显式指定StandardCharsets.UTF_8；缓冲能大幅提升性能，BufferedReader的readLine()是文本处理关键。

Reader 和 Writer 是一对抽象基类，分工明确：Reader 专用于读取字符，Writer 专用于写入字符。它们不是互为反向操作的“镜像”，而是从设计上就分离了输入与输出职责，且各自方法签名、异常行为、缓冲策略都不同——直接混用或误认为可互相替代，是初学者最常踩的坑。

---

为什么不能用 Reader 写数据，也不能用 Writer 读数据？

这是由接口契约决定的：Reader 只定义了 read()、read(char[]) 等输入方法，没有 write()；Writer 只有 write()、flush()、close()，没有 read()。编译器会直接报错，比如：

Reader r = new FileReader("a.txt");
r.write('x'); // ❌ 编译错误：cannot resolve method 'write(char)'

更深层原因是：Java 的 IO 分层模型中，输入流（Reader/InputStream）和输出流（Writer/OutputStream）属于不同分支，不可跨支调用。强行“倒着用”在语义和实现上都不成立。

---

FileReader 和 FileWriter 的默认编码有多危险？

这两个类的无参构造函数（如 new FileReader("a.txt")）会使用 Charset.defaultCharset()，也就是操作系统当前默认编码（Windows 上通常是 GBK，Linux/macOS 多为 UTF-8）。一旦读写两端编码不一致，中文立刻变 ??? 或乱码字节。

• 写入时用 FileWriter 默认编码（GBK），读取时用 BufferedReader 指定 UTF_8 → 乱码
• 文件本身是 UTF-8 编码，但用 FileReader 直接打开 → 读出的中文字符被截断或替换为
• 跨平台部署时，同一段代码在开发机（UTF-8）和生产服务器（GBK）行为不一致

✅ 正确做法：显式传入 StandardCharsets.UTF_8，绕过默认编码：

Reader r = new InputStreamReader(new FileInputStream("a.txt"), StandardCharsets.UTF_8);
Writer w = new OutputStreamWriter(new FileOutputStream("b.txt"), StandardCharsets.UTF_8);

注意：FileReader/FileWriter 本身不支持指定编码（构造函数无 charset 参数），必须升一级用 InputStreamReader/OutputStreamWriter。

---

缓冲为什么不能省？BufferedReader 和 BufferedWriter 怎么配对用？

逐字符读写（Reader.read() / Writer.write(int)）会频繁触发系统调用，性能极差；而 BufferedReader 和 BufferedWriter 在内存中维护缓冲区，一次批量读/写几十 KB，吞吐量可提升 10 倍以上。

• BufferedReader 提供 readLine() —— 这是处理文本文件最常用的方法，自动识别 \n、、\r
• BufferedWriter 提供 newLine() —— 它会写入当前平台的换行符（Windows 是 \r\n，其他多为 \n），比手动写 "\n" 更可靠
• 二者必须成对使用：用 BufferedReader 包装带编码的 InputStreamReader，用 BufferedWriter 包装带编码的 OutputStreamWriter

✅ 推荐组合（带资源自动关闭）：

try (BufferedReader br = new BufferedReader(
        new InputStreamReader(new FileInputStream("in.txt"), StandardCharsets.UTF_8));
     BufferedWriter bw = new BufferedWriter(
        new OutputStreamWriter(new FileOutputStream("out.txt"), StandardCharsets.UTF_8))) {
    String line;
    while ((line = br.readLine()) != null) {
        bw.write(line.toUpperCase());
        bw.newLine();
    }
}

---

资源不关、异常不处理，Reader/Writer 就会“咬人”

忘记 close() 会导致文件句柄泄漏，尤其在高并发或长期运行服务中，可能触发 java.io.IOException: Too many open files；而未捕获 IOException 会让程序在读写失败时直接崩溃，且流未关闭。

✅ 唯一稳妥做法：用 try-with-resources —— 它要求资源类型实现 AutoCloseable（Reader 和 Writer 都满足）：

try (Reader r = new InputStreamReader(is, UTF_8);
     Writer w = new OutputStreamWriter(os, UTF_8)) {
    // 使用 r 和 w
} // ✅ 自动调用 close()，无论是否异常

别信“JVM 会帮你关”——它不会。也别用 finally 手动关，容易因二次关闭或空指针引发新异常。

真正的麻烦往往不在“怎么读写”，而在“谁来管编码、谁来管缓冲、谁来关流”。这三个点没对齐，哪怕逻辑再简单，也会在某次上线后凌晨三点弹出乱码告警。