InputStream/OutputStream read()/write()函数相关性及用法答案

【问题标题】：InputStream/OutputStream read()/write() function relevance and usageInputStream/OutputStream read()/write()函数相关性及用法
【发布时间】：2013-09-23 20:36:56
【问题描述】：

对于java.io.InputStream，有两个主要的读取函数int read()和public int read(byte[] b, int off, int len) .

同样，对于 java.io.OutputStream 有两个函数 write(b) 和 write((byte[] b, int off, int len))

虽然我了解基本区别，但在阅读 write(b) 的描述时，它说“要写入的字节是参数 b 的 8 个低位。24 个高位的 b 被忽略。”。现在如果是这种情况，那么我们实际上是在浪费 CPU 会为整数加载的 32 位指令集中剩余的 24 位。相反，如果我使用另一个写入 ((byte[] b, int off, int len))，那么我将占用堆/堆栈来获取字节数组的大小。虽然我试图考虑哪个更适合高可扩展性，但我不能忽略 write(b) 浪费 24 位（3 个字节），而另一方面，如果我使用 read/write(byte[] b, int off, int len)，我冒着更高的堆栈大小的风险。那么，最好的选择是什么？

在一种解决方法中，我尝试扩展 InputStream 和 OutputStream 并通过提供一个字节 [4] 来使用所有 32 位来覆盖 read(b) 和 write(b) 函数。它工作得很好，但仍然需要看看这是否有任何性能增强。它非常类似于使用 read/write(4, 0, int 4)

我将不胜感激有关此主题的任何帮助/评论。

【问题讨论】：

标签： java

【解决方案1】：

如果你想达到速度，你可能想一次读.写几个字节。例如，如果您想在磁盘上写入/读取某些内容，您可能希望一次读取/写入整个扇区（4k 或 8k 字节）。

此外，这样做可以最大限度地减少系统调用的数量，因此应用程序会更快。

关于堆栈，在 java 中，字节数组将在堆上，并且只有引用存储在堆栈上，正如@Mike 提到的那样。

【讨论】：

谢谢。声明 4K/8K 字节是一个很好的提示。但是，你不觉得在堆上声明一个相当于硬盘扇区的块会很大吗？您不认为对于具有局部变量的函数，整个数组将被复制到堆栈中吗？如果字节数组是一个类变量，我知道它自然是一个引用，因为 byte[] 声明在堆上。
@Ashley，我认为您对数组在 Java 中的工作方式存在误解。见this question。数组总是存储在堆上。
@Ashley 4k/8k 在磁盘上与 jvm 为应用程序存储在内存中的其他内容相比非常小。
再次感谢。我认为现在很清楚数组总是存储在堆上，而不管它们的范围是类还是本地函数。这也阐明了为什么 read/write(byte[]) 更好。另一方面，我对您关于磁盘扇区的回答有些困惑。 4K/8K对于硬盘来说很小，但是对于一个数组大小（当它加载到内存时）来说，它仍然是一个很大的数字。不是吗？
@Ashley 例如，如果您的 PC 具有 1GB=1024MB=1048576KB 的 RAM，那么 4KB 真的非常非常小。

【解决方案2】：

使用带有byte[] 的版本不会将整个字节数组压入堆栈。您将对字节数组的引用压入堆栈。

除非您只写一个字节，否则最好使用带有byte[] 的版本。

【讨论】：

谢谢迈克。您不认为对于具有局部变量的函数，整个数组将被复制到堆栈中吗？如果字节数组是一个类变量，我知道它自然是一个引用，因为 byte[] 声明在堆上。请。让我知道你的想法。
没有。您可以在Java Language Specification 中找到更多相关信息。数组实际上被语言视为对象，并且总是这样传递。
再次感谢迈克。我认为您的澄清消除了我的疑虑。在下面的这篇文章中，@csoroiu 建议使用大小为 4K/8k 的字节数组（等于硬盘上的扇区）。声明 4K/8K 字节是一个很好的提示。但是，你不觉得在堆上声明一个相当于硬盘扇区的chunk会很大吗？
在我看来，一次写入的字节数越多越好。（通常）几千字节的空间应该不是问题，具体取决于规模。（多少个线程？你多久分配一次空间？等等）
谢谢。关于 write(b) 的任何评论都浪费了 24 位（3 字节）？