具体而言，问题是编写一个像这样的方法：
int maybeRead(InputStream in, long timeout)
如果在'timeout'毫秒内有数据可用，则返回值与in.read()相同，否则返回-2。方法返回之前，任何生成的线程都必须退出。
为避免争论，这里涉及到Java.io.InputStream主题，该主题由Sun（任何Java版本）记录。请注意，这并不像看起来那么简单。以下是一些根据Sun文档直接支持的事实。
in.read()方法可能是不可中断的。
包装InputStream在Reader或InterruptibleChannel中没有帮助，因为所有这些类能做的就是调用InputStream的方法。如果可以使用这些类，那么就可以编写一个解决方案，直接在InputStream上执行相同的逻辑。
in.available()始终可返回0。
in.close()方法可能会阻塞或不执行任何操作。
没有通用的方法可以杀死另一个线程。
使用inputStream.available()
System.in.available() 返回 0 始终是可以接受的。
我发现相反的情况 - 它总是返回可用字节数的最佳值。根据 InputStream.available() 的JavaDoc：
Returns an estimate of the number of bytes that can be read (or skipped over)
from this input stream without blocking by the next invocation of a method for
this input stream.
由于时间/陈旧性，估计是不可避免的。该数字可能会因为新数据的不断到来而被低估一次。但是它总是在下一个调用中“追上”——它应该考虑到所有到达的数据，除了刚好在新调用时刻到达的数据。如果有数据却永久返回0，则无法满足以上条件。
第一个注意点：具体的InputStream子类负责available()
InputStream是一个抽象类。它没有数据源。它拥有可用数据是毫无意义的。因此，available()的javadoc也说明：
The available method for class InputStream always returns 0.
This method should be overridden by subclasses.
实际上，具体的输入流类确实覆盖了available()方法，提供有意义的值而不是常数0。
第二个警告：在Windows中键入输入时，请确保使用回车符。
如果使用System.in，则当您的命令行程序将其传递时，您的程序才会收到输入。如果您正在使用文件重定向/管道（例如somefile > java myJavaApp或somecommand | java myJavaApp），则输入数据通常会立即传递。但是，如果您手动输入数据，则数据传递可能会延迟。例如，在Windows cmd.exe shell中，数据会缓冲在cmd.exe shell中。只有在按下回车键（控制-M或<enter>）后，数据才会传递给执行的Java程序。这是执行环境的限制。当然，InputStream.available()在shell缓冲数据时将返回0 - 这是正确的行为；此时没有可用的数据。一旦数据从shell可用，该方法将返回一个大于0的值。注意：Cygwin也使用cmd.exe。
只需使用以下内容：
byte[] inputData = new byte[1024];
int result = is.read(inputData, 0, is.available());
// result will indicate number of bytes read; -1 for EOF with no data read.
或等价地说，
BufferedReader br = new BufferedReader(new InputStreamReader(System.in, Charset.forName("ISO-8859-1")),1024);
// ...
// inside some iteration / processing logic:
if (br.ready()) {
int readCount = br.read(inputData, bufferOffset, inputData.length-bufferOffset);
}
声明如下：
public static int readInputStreamWithTimeout(InputStream is, byte[] b, int timeoutMillis)
throws IOException {
int bufferOffset = 0;
long maxTimeMillis = System.currentTimeMillis() + timeoutMillis;
while (System.currentTimeMillis() < maxTimeMillis && bufferOffset < b.length) {
int readLength = java.lang.Math.min(is.available(),b.length-bufferOffset);
// can alternatively use bufferedReader, guarded by isReady():
int readResult = is.read(b, bufferOffset, readLength);
if (readResult == -1) break;
bufferOffset += readResult;
}
return bufferOffset;
}
然后使用这个：
byte[] inputData = new byte[1024];
int readCount = readInputStreamWithTimeout(System.in, inputData, 6000); // 6 second timeout
// readCount will indicate number of bytes read; -1 for EOF with no data read.
假设您的流不是由套接字支持的(所以无法使用 Socket.setSoTimeout())，我认为解决这类问题的标准方法是使用 Future。
假设我有以下执行器和流：
ExecutorService executor = Executors.newFixedThreadPool(2);
final PipedOutputStream outputStream = new PipedOutputStream();
final PipedInputStream inputStream = new PipedInputStream(outputStream);
我有一个写入器，它会写入一些数据，然后等待5秒钟，然后再写入最后一块数据并关闭流：
Runnable writeTask = new Runnable() {
@Override
public void run() {
try {
outputStream.write(1);
outputStream.write(2);
Thread.sleep(5000);
outputStream.write(3);
outputStream.close();
} catch (Exception e) {
e.printStackTrace();
}
}
};
executor.submit(writeTask);
正常的阅读方式如下。读取操作会一直阻塞直到有数据可用，因此这个过程需要5秒钟完成：
long start = currentTimeMillis();
int readByte = 1;
// Read data without timeout
while (readByte >= 0) {
readByte = inputStream.read();
if (readByte >= 0)
System.out.println("Read: " + readByte);
}
System.out.println("Complete in " + (currentTimeMillis() - start) + "ms");
输出结果为：
Read: 1
Read: 2
Read: 3
Complete in 5001ms
如果存在更根本的问题，例如写程序没有响应，那么读程序将会一直阻塞。 如果我将读操作包装在一个future中，我可以按以下方式控制超时：
int readByte = 1;
// Read data with timeout
Callable<Integer> readTask = new Callable<Integer>() {
@Override
public Integer call() throws Exception {
return inputStream.read();
}
};
while (readByte >= 0) {
Future<Integer> future = executor.submit(readTask);
readByte = future.get(1000, TimeUnit.MILLISECONDS);
if (readByte >= 0)
System.out.println("Read: " + readByte);
}
输出结果为：
Read: 1
Read: 2
Exception in thread "main" java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228)
at java.util.concurrent.FutureTask.get(FutureTask.java:91)
at test.InputStreamWithTimeoutTest.main(InputStreamWithTimeoutTest.java:74)
我可以捕获TimeoutException并进行任何所需的清理操作。
如果您的InputStream由Socket支持，您可以使用setSoTimeout设置Socket超时时间（以毫秒为单位）。 如果在指定的超时时间内read()调用不解除阻塞，则会抛出SocketTimeoutException。
只需确保在进行read()调用之前在Socket上调用setSoTimeout。
我会质疑问题陈述而不是盲目接受它。你只需要从控制台或网络中获得超时时间。如果是后者，你可以使用Socket.setSoTimeout()和HttpURLConnection.setReadTimeout()，它们都能够完全满足要求，只要在构建/获取它们时正确设置即可。在应用程序的任意后一点留给InputStream处理超时，这是很差的设计，并导致非常尴尬的实现。
我从未使用过Java NIO包中的类，但是它们似乎在这里可能会有所帮助。具体来说，java.nio.channels.Channels和java.nio.channels.InterruptibleChannel。
以下是一种从System.in获取NIO FileChannel并使用超时检查数据可用性的方法，这是问题描述中的特殊情况。在控制台上运行它，不要输入任何内容，等待结果。在Windows和Linux上成功地测试了Java 6。
import java.io.FileInputStream;
import java.io.FilterInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Field;
import java.nio.ByteBuffer;
import java.nio.channels.ClosedByInterruptException;
public class Main {
static final ByteBuffer buf = ByteBuffer.allocate(4096);
public static void main(String[] args) {
long timeout = 1000 * 5;
try {
InputStream in = extract(System.in);
if (! (in instanceof FileInputStream))
throw new RuntimeException(
"Could not extract a FileInputStream from STDIN.");
try {
int ret = maybeAvailable((FileInputStream)in, timeout);
System.out.println(
Integer.toString(ret) + " bytes were read.");
} finally {
in.close();
}
} catch (Exception e) {
throw new RuntimeException(e);
}
}
/* unravels all layers of FilterInputStream wrappers to get to the
* core InputStream
*/
public static InputStream extract(InputStream in)
throws NoSuchFieldException, IllegalAccessException {
Field f = FilterInputStream.class.getDeclaredField("in");
f.setAccessible(true);
while( in instanceof FilterInputStream )
in = (InputStream)f.get((FilterInputStream)in);
return in;
}
/* Returns the number of bytes which could be read from the stream,
* timing out after the specified number of milliseconds.
* Returns 0 on timeout (because no bytes could be read)
* and -1 for end of stream.
*/
public static int maybeAvailable(final FileInputStream in, long timeout)
throws IOException, InterruptedException {
final int[] dataReady = {0};
final IOException[] maybeException = {null};
final Thread reader = new Thread() {
public void run() {
try {
dataReady[0] = in.getChannel().read(buf);
} catch (ClosedByInterruptException e) {
System.err.println("Reader interrupted.");
} catch (IOException e) {
maybeException[0] = e;
}
}
};
Thread interruptor = new Thread() {
public void run() {
reader.interrupt();
}
};
reader.start();
for(;;) {
reader.join(timeout);
if (!reader.isAlive())
break;
interruptor.start();
interruptor.join(1000);
reader.join(1000);
if (!reader.isAlive())
break;
System.err.println("We're hung");
System.exit(1);
}
if ( maybeException[0] != null )
throw maybeException[0];
return dataReady[0];
}
}
有趣的是，在NetBeans 6.5内运行程序而不是在控制台中运行时，超时根本不起作用，并且调用System.exit()实际上是必要的来终止僵尸线程。发生的情况是中断线程在调用reader.interrupt()时阻塞(!)。另一个测试程序（此处未显示）还尝试关闭通道，但也无法正常工作。
Socket.setSoTimeout() 是同样正确且更简单的解决方案。或者使用 HttpURLConnection.setReadTimeout()。 - user207421InputStream.read() 是一个IO调用。在等待字节/超时时，它不应该占用任何CPU资源。据我所知，Java提供的read()支持适当的阻塞，但没有任何超时功能。大多数其他回答这个StackOverflow问题的答案都提供了超时功能，但使用了忙等待。
在没有忙等待的情况下，无法为InputStream实现超时。
Socket.setSoTimeout违反了面向对象编程原则Socket.getInputStream()返回的InputStream扩展了class InputStream。根据其API，InputStream.read()是一个抽象方法，只允许抛出IOException以外的任何异常。然而，引用Socket.setSoTimeout()的API：
Selector.select(timeout) 实现了非忙等待。SocketTimeoutException 继承自 InterruptedIOException，后者又继承自 IOException。public class SafeBufferedReader extends BufferedReader{
private long millisTimeout;
( . . . )
@Override
public int read(char[] cbuf, int off, int len) throws IOException {
try {
waitReady();
} catch(IllegalThreadStateException e) {
return 0;
}
return super.read(cbuf, off, len);
}
protected void waitReady() throws IllegalThreadStateException, IOException {
if(ready()) return;
long timeout = System.currentTimeMillis() + millisTimeout;
while(System.currentTimeMillis() < timeout) {
if(ready()) return;
try {
Thread.sleep(100);
} catch (InterruptedException e) {
break; // Should restore flag
}
}
if(ready()) return; // Just in case.
throw new IllegalThreadStateException("Read timed out");
}
}
这里有一个几乎完整的例子。
在一些方法中，我返回0，但你应该将其更改为-2以满足你的需求，不过我认为0更适合BufferedReader协议。没有发生错误，只是读取了0个字符。readLine方法会严重影响性能。如果你真的想使用readLine，你应该创建一个全新的BufferedReader。目前它不是线程安全的。如果在readLine等待行时有人调用操作，它将产生意想不到的结果。
我不喜欢在这里返回-2。我会抛出异常，因为有些人可能只是检查int < 0来考虑EOS。无论如何，这些方法声称“不能阻塞”，你应该检查该语句是否真实，并且不要覆盖它们。
import java.io.BufferedReader;
import java.io.IOException;
import java.io.Reader;
import java.nio.CharBuffer;
import java.util.concurrent.TimeUnit;
import java.util.stream.Stream;
/**
*
* readLine
*
* @author Dario
*
*/
public class SafeBufferedReader extends BufferedReader{
private long millisTimeout;
private long millisInterval = 100;
private int lookAheadLine;
public SafeBufferedReader(Reader in, int sz, long millisTimeout) {
super(in, sz);
this.millisTimeout = millisTimeout;
}
public SafeBufferedReader(Reader in, long millisTimeout) {
super(in);
this.millisTimeout = millisTimeout;
}
/**
* This is probably going to kill readLine performance. You should study BufferedReader and completly override the method.
*
* It should mark the position, then perform its normal operation in a nonblocking way, and if it reaches the timeout then reset position and throw IllegalThreadStateException
*
*/
@Override
public String readLine() throws IOException {
try {
waitReadyLine();
} catch(IllegalThreadStateException e) {
//return null; //Null usually means EOS here, so we can't.
throw e;
}
return super.readLine();
}
@Override
public int read() throws IOException {
try {
waitReady();
} catch(IllegalThreadStateException e) {
return -2; // I'd throw a runtime here, as some people may just be checking if int < 0 to consider EOS
}
return super.read();
}
@Override
public int read(char[] cbuf) throws IOException {
try {
waitReady();
} catch(IllegalThreadStateException e) {
return -2; // I'd throw a runtime here, as some people may just be checking if int < 0 to consider EOS
}
return super.read(cbuf);
}
@Override
public int read(char[] cbuf, int off, int len) throws IOException {
try {
waitReady();
} catch(IllegalThreadStateException e) {
return 0;
}
return super.read(cbuf, off, len);
}
@Override
public int read(CharBuffer target) throws IOException {
try {
waitReady();
} catch(IllegalThreadStateException e) {
return 0;
}
return super.read(target);
}
@Override
public void mark(int readAheadLimit) throws IOException {
super.mark(readAheadLimit);
}
@Override
public Stream<String> lines() {
return super.lines();
}
@Override
public void reset() throws IOException {
super.reset();
}
@Override
public long skip(long n) throws IOException {
return super.skip(n);
}
public long getMillisTimeout() {
return millisTimeout;
}
public void setMillisTimeout(long millisTimeout) {
this.millisTimeout = millisTimeout;
}
public void setTimeout(long timeout, TimeUnit unit) {
this.millisTimeout = TimeUnit.MILLISECONDS.convert(timeout, unit);
}
public long getMillisInterval() {
return millisInterval;
}
public void setMillisInterval(long millisInterval) {
this.millisInterval = millisInterval;
}
public void setInterval(long time, TimeUnit unit) {
this.millisInterval = TimeUnit.MILLISECONDS.convert(time, unit);
}
/**
* This is actually forcing us to read the buffer twice in order to determine a line is actually ready.
*
* @throws IllegalThreadStateException
* @throws IOException
*/
protected void waitReadyLine() throws IllegalThreadStateException, IOException {
long timeout = System.currentTimeMillis() + millisTimeout;
waitReady();
super.mark(lookAheadLine);
try {
while(System.currentTimeMillis() < timeout) {
while(ready()) {
int charInt = super.read();
if(charInt==-1) return; // EOS reached
char character = (char) charInt;
if(character == '\n' || character == '\r' ) return;
}
try {
Thread.sleep(millisInterval);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // Restore flag
break;
}
}
} finally {
super.reset();
}
throw new IllegalThreadStateException("readLine timed out");
}
protected void waitReady() throws IllegalThreadStateException, IOException {
if(ready()) return;
long timeout = System.currentTimeMillis() + millisTimeout;
while(System.currentTimeMillis() < timeout) {
if(ready()) return;
try {
Thread.sleep(millisInterval);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // Restore flag
break;
}
}
if(ready()) return; // Just in case.
throw new IllegalThreadStateException("read timed out");
}
}
is.available() > 1024，这个建议将会失败。当然有一些流（streams）确实会返回0，例如直到最近的SSLSockets也是如此。你不能依赖这一点。 - user207421