files.newinputstream() 返回的 inputstream 虽可逐字节读取，但单字节 read() 性能极差；应使用 byte[] 缓冲区配合 read(byte[]) 高效读取，注意处理实际读取字节数 n，避免 while((b=in.read())!=-1) 反模式。
Files.newInputStream() 本身不提供逐字节读取能力
Files.newInputStream() 返回的是 InputStream，它确实能读二进制数据，但它的 read() 方法每次只返回一个 int（0–255 或 -1），表面看是“逐字节”，实际性能极差——每次调用都触发一次系统调用或缓冲区检查，完全违背 I/O 设计本意。
真正底层、高效的做法是配合缓冲区使用，而不是依赖单字节 read()。如果你真需要“逐字节语义”（比如解析协议头、跳过 magic bytes），也应基于 read(byte[]) 手动拆解，而非反复调用单字节版本。
正确用法：用 byte[] 缓冲 + read(byte[]) 避免性能陷阱
直接调用 in.read(byte[]) 是标准且高效的路径。JVM 和底层 OS 会自动利用 page cache、预读等机制，吞吐量可达单字节模式的百倍以上。
- 始终分配合理大小的缓冲区，如
new byte[8192]（常见页大小） - 注意
read(byte[])返回值是“本次实际读到的字节数”，可能小于数组长度，也可能是 0（非错误，需继续读） - 不要用
while ((b = in.read()) != -1)—— 这是典型反模式，尤其对大文件会慢得不可接受
try (InputStream in = Files.newInputStream(Paths.get("data.bin"))) {
byte[] buf = new byte[8192];
int n;
while ((n = in.read(buf)) != -1) {
// 处理 buf[0] 到 buf[n-1] 的 n 个字节
for (int i = 0; i
<h3>如果必须边读边判断单字节（如解析变长 header），别阻塞在 read() 上</h3>
<p>某些协议要求“读一个字节，根据值决定是否继续读”，这时容易写出 <code>read()</code> 嵌套循环。问题在于：如果文件末尾只剩半个结构，<code>read()</code> 可能阻塞或抛 <code>EOFException</code>（取决于封装层），而原生 <code>InputStream</code> 只返回 -1。</p>
- 优先用
read(byte[], off, len)读固定最小单元（如 1 字节），检查返回值是否为 1 - 避免在循环内反复 new byte[1] —— 分配开销明显，复用一个
byte[1]数组即可 - 注意：NIO 的
FileChannel+ByteBuffer更适合这类精细控制，但Files.newInputStream()不暴露 channel，需改用Files.newByteChannel()
byte[] single = new byte[1];
try (InputStream in = Files.newInputStream(Paths.get("hdr.bin"))) {
while (true) {
int r = in.read(single);
if (r == -1) break; // EOF
if (r != 1) throw new IOException("short read");
byte b = single[0];
if (b == (byte)0xFF) break; // 示例：遇到 0xFF 结束
// ...
}
}
为什么不用 BufferedInputStream 包一层？
很多人第一反应是加 new BufferedInputStream(Files.newInputStream(...))。这看似合理，但多余——Files.newInputStream() 在大多数实现（如 UnixFileSystem）中已内置缓冲逻辑，再套一层只会增加对象开销和间接调用层级。
- 除非你明确需要 mark/reset 功能（
InputStream默认不支持），否则没必要包装 - 若需 reset，应改用
Files.readAllBytes()加ByteArrayInputStream，或直接用RandomAccessFile - Windows 上
Files.newInputStream()底层调用CreateFile+ReadFile，本身就有系统级缓冲
