System.in 属于哪个输入类，为什么？答案

【问题标题】：What input class does System.in belongs to and why?System.in 属于哪个输入类，为什么？
【发布时间】：2015-08-17 13:37:13
【问题描述】：

代码

import java.io.*;

class ioTest1{
   public static void main(String args[]){
      System.out.println(System.in.getClass());
   }
}

返回 System.in 属于 BufferedInputStream 类。这是为什么呢？

由于System 类将System.in 定义为InputStream，我可以看到结果并非不可能。但是为什么前面的代码不能返回另一个继承自InputStream的类，比如DataInputStream？

【问题讨论】：

如果编写类的人决定选择另一个实现，它可能会返回扩展 InputStream 类的其他内容。
BufferedInputStream 是InputStream 的子类。 getClass() 可以返回 InputStream 的任何子类，但它返回 BufferedInputStream 的原因是因为这就是它的实现方式——也就是说，在某个地方，你会找到一条大致说明的行System.in = new BufferedInputStream()（而不是其他类型的流）。您是在问开发者选择这种类型的流的原因吗？
如果是代表开发人员实施的问题，那么这就回答了我的问题。但我试图了解 I/O 在 Java 中是如何工作的，我认为让这样一个指定的类实例化通用标准输入流很奇怪......
@ThemistoklisHaris 因为InputStream 是抽象的，所以它必须是子类之一。 BufferedInputStream 是一个非常合适且显而易见的选择。
@Kayaman 为什么BufferedInputStream 比InputStream 的其他风格更好？（这将是这个问题的一个很好的答案；））

【解决方案1】：

正如 cmets 中所解释的，没有什么可以阻止 System.in 成为 DataInputStream，但鉴于 BufferedInputStream 是一个简洁的 InputStream，其中包括数据缓冲（总是一个好主意），尽可能给出最通用的类型更有意义。

然后，如果程序接收管道二进制数据，开发人员可以使用 DataInputStream 包装缓冲流，如果程序从用户接收文本数据，则使用 InputStreamReader。

System.in 是 BufferedInputStream，因为它不需要是其他任何东西。

【讨论】：

【解决方案2】：

简单的答案是它是如何实现的。

如果您查看 java.lang.System 类的源代码，您会看到 System.in 设置为 natively（参见 Java_java_lang_System_setIn0）。

不同的 JVM 实现者可以使用他们喜欢的任何 InputStream 实现。在您的情况下，使用 BufferedInputStream 大概是为了提高效率。

【讨论】：