为什么InputStream的read()方法返回int而不是short？

Question

我正在阅读字节流试用，并注意到以下声明：

请注意，read（）返回int值。如果输入是一串字节，为什么read（）不返回byte值？使用int作为返回类型允许read（）使用-1来指示它已经到达流的末尾。

使用int的原因是它们可以通过-1来识别EOF。（似乎很肤浅）

那么下一个更大的原始类型是short，它也支持-1，为什么不使用它？

从我所了解的：（使用int的原因）

1. 由于性能原因，首选使用int类型。 (点击此处)
2. int变量在其最后16位中保存字符值（来自字符试验）。
3. 其他更抽象的流需要读取多个字节（这似乎是字符流的情况）。

我的理由正确吗？我是否遗漏了什么（比如错误纠正）？

- boxed__l

Answer 1

首选int而不是short的最重要原因是，short有点像二等公民：所有整数字面值以及所有算术运算都是int类型的，因此在许多地方都会发生short->int提升。此外，几乎没有任何反对使用int的论据。

- Marko Topolnik

---

在Java被设计的时候，标准的CPU架构是32位，因此int可能是可以以最快速度使用的最大数值类型，所以为什么不使用它呢？因为它更大，所以它的寿命会更长。我严重怀疑使用short会节省时间或内存。 - Bohemian

Answer 2

只有在处理大量的short类型数组时，使用short才能带来优势。确保只在明确数字符合范围的情况下使用它们。

在其他所有情况下，无论你使用short还是int，都不会有实质性的区别。例如：

class A {
    short s;
    double d;
}

不会比以下占用更少的内存：

class B {
    int s;
    double d;
}

由于对齐问题，第一个对象只有净数据10字节，而第二个对象有12字节。但是，当您分配对象时，它仍将对齐到某个8字节边界。即使它只是4字节边界，内存使用量也将相同。

- Ingo

---

+1 jls建议仅使用short来节省空间。 - boxed__l

Answer 3

这是一个有趣的问题 :-)。确实，他们必须使用有符号整数值类型来表示EOF，但是偏好int而不是short可能真的只是出于性能方面的考虑。

正如我在另一个StackOverflow线程上发现的，在那里讨论了这个问题，即使定义使用了short，Java VM也会自动在内部使用int。

Java文档指出，应在大型数组和内存真正重要的情况下使用short - 来源 - http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html。这显然不是这种情况，因为我们总是只得到一个值。

- Martin Zikmund

---

但是如何强制执行“short”溢出呢？这需要额外的操作，并且与“int”一起免费提供（当然，前提是具有本地指令支持，但基本假设是由于缺乏本地“short”支持，“int”更快）。 - Marko Topolnik