É possível ler de um InputStream com um tempo limite?

Especificamente, o problema é escrever um método como este:

int maybeRead(InputStream in, long timeout)

onde o valor de retorno é o mesmo que in.read () se os dados estiverem disponíveis dentro de 'timeout' milissegundos e -2 caso contrário. Antes do método retornar, todos os threads gerados devem sair.

Para evitar argumentos, o assunto aqui java.io.InputStream, conforme documentado pela Sun (qualquer versão do Java). Observe que isso não é tão simples quanto parece. Abaixo estão alguns fatos suportados diretamente pela documentação da Sun.

1. O método in.read () pode ser ininterrupto.

2. Quebrar o InputStream em um Reader ou InterruptibleChannel não ajuda, porque tudo o que essas classes podem fazer é chamar métodos do InputStream. Se fosse possível usar essas classes, seria possível escrever uma solução que apenas execute a mesma lógica diretamente no InputStream.

3. É sempre aceitável que in.available () retorne 0.

4. O método in.close () pode bloquear ou não fazer nada.

5. Não existe uma maneira geral de eliminar outro segmento.

Usando inputStream.available ()

É sempre aceitável que System.in.available () retorne 0.

Eu descobri o contrário - ele sempre retorna o melhor valor para o número de bytes disponíveis. Javadoc para InputStream.available():

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.

Uma estimativa é inevitável devido ao tempo / estabilidade. A figura pode ser uma subestimação pontual porque novos dados estão chegando constantemente. No entanto, ele sempre "alcança" a próxima chamada - deve ser responsável por todos os dados recebidos, exceto pelos que chegam exatamente no momento da nova chamada. Retornar permanentemente 0 quando houver dados falha na condição acima.

Primeira advertência: as subclasses de concreto do InputStream são responsáveis ​​pela disponibilidade ()

InputStreamé uma classe abstrata. Não possui fonte de dados. Não faz sentido ter dados disponíveis. Portanto, o javadoc para available()também declara:

The available method for class InputStream always returns 0.

This method should be overridden by subclasses.

E, de fato, as classes concretas do fluxo de entrada substituem available (), fornecendo valores significativos, não 0s constantes.

Segunda Advertência: Certifique-se de usar retorno de carro ao digitar entrada no Windows.

Se estiver usando System.in, seu programa só recebe entrada quando seu shell de comando o entrega. Se você estiver usando redirecionamentos de arquivo / pipes (por exemplo, somefile> java myJavaApp ou algum comando | java myJavaApp), os dados de entrada geralmente são entregues imediatamente. No entanto, se você digitar manualmente a entrada, a transferência de dados poderá ser atrasada. Por exemplo, com o shell do cmd.exe do windows, os dados são armazenados em buffer no shell do cmd.exe. Os dados são passados ​​apenas para o programa java em execução após retorno de carro (control-m ou <enter>). Essa é uma limitação do ambiente de execução. Obviamente, InputStream.available () retornará 0 enquanto o shell armazenar em buffer os dados - esse é o comportamento correto; não há dados disponíveis nesse ponto. Assim que os dados estiverem disponíveis no shell, o método retornará um valor> 0. NB: Cygwin usa cmd.

Solução mais simples (sem bloqueio, portanto, não é necessário tempo limite)

Apenas use isto:

    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.

Ou equivalente,

    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);
         }

Solução mais rica (preenche o buffer no máximo dentro do período de tempo limite)

Declare isso:

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;
 }

Então use isto:

    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.

Supondo que seu fluxo não seja suportado por um soquete (então você não pode usá-lo Socket.setSoTimeout()), acho que a maneira padrão de resolver esse tipo de problema é usar um futuro.

Suponha que eu tenha o seguinte executor e fluxos:

    ExecutorService executor = Executors.newFixedThreadPool(2);
    final PipedOutputStream outputStream = new PipedOutputStream();
    final PipedInputStream inputStream = new PipedInputStream(outputStream);

Eu tenho um escritor que grava alguns dados e aguarda 5 segundos antes de gravar o último dado e fechar o fluxo:

    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);

A maneira normal de ler isso é a seguinte. A leitura bloqueará indefinidamente os dados e, portanto, isso será concluído em 5s:

    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");

quais saídas:

Read: 1
Read: 2
Read: 3
Complete in 5001ms

Se houvesse um problema mais fundamental, como o escritor não responder, o leitor iria bloquear para sempre. Se eu encerrar a leitura em um futuro, posso controlar o tempo limite da seguinte maneira:

    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);
    }

quais saídas:

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)

Eu posso pegar a TimeoutException e fazer a limpeza que eu quiser.

Se o seu InputStream for apoiado por um Socket, você poderá definir um tempo limite de Socket (em milissegundos) usando setSoTimeout . Se a chamada read () não desbloquear dentro do tempo limite especificado, lançará uma SocketTimeoutException.

Apenas certifique-se de chamar setSoTimeout no soquete antes de fazer a chamada read ().

Eu questionaria a declaração do problema em vez de apenas aceitá-la cegamente. Você só precisa de tempos limite no console ou na rede. Se o último que você possui Socket.setSoTimeout()e os HttpURLConnection.setReadTimeout()dois fazem exatamente o que é necessário, desde que você os configure corretamente ao construí-los / adquiri-los. Deixando-o para um ponto arbitrário mais tarde no aplicativo, quando tudo o que você tem é o InputStream é um design ruim, levando a uma implementação muito complicada.

Eu não usei as classes do pacote Java NIO, mas parece que elas podem ser de alguma ajuda aqui. Especificamente, java.nio.channels.Channels e java.nio.channels.InterruptibleChannel .

Aqui está uma maneira de obter um NIO FileChannel do System.in e verificar a disponibilidade de dados usando um tempo limite, que é um caso especial do problema descrito na pergunta. Execute-o no console, não digite nenhuma entrada e aguarde os resultados. Foi testado com sucesso no Java 6 no Windows e Linux.

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];
    }
}

Curiosamente, ao executar o programa no NetBeans 6.5 e não no console, o tempo limite não funciona e a chamada para System.exit () é realmente necessária para eliminar os threads zumbis. O que acontece é que o encadeamento do interruptor bloqueia (!) A chamada para reader.interrupt (). Outro programa de teste (não mostrado aqui) também tenta fechar o canal, mas isso também não funciona.

Como disse jt, o NIO é a melhor (e correta) solução. Se você realmente está preso a um InputStream, você pode

1. Gera um thread cujo trabalho exclusivo é ler o InputStream e colocar o resultado em um buffer que pode ser lido no seu thread original sem bloquear. Isso deve funcionar bem se você tiver apenas uma instância do fluxo. Caso contrário, você poderá eliminar o encadeamento usando os métodos descontinuados na classe Thread, embora isso possa causar vazamentos de recursos.

2. Confie em isAvailable para indicar dados que podem ser lidos sem bloqueio. No entanto, em alguns casos (como em Sockets), pode levar uma leitura potencialmente bloqueadora para isAvailable para relatar algo diferente de 0.

Inspirado nesta resposta , criei uma solução um pouco mais orientada a objetos.

Isso é válido apenas se você pretende ler caracteres

Você pode substituir o BufferedReader e implementar algo como isto:

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");
    }
}

Aqui está um exemplo quase completo.

Estou retornando 0 em alguns métodos, você deve alterá-lo para -2 para atender às suas necessidades, mas acho que 0 é mais adequado ao contrato BufferedReader. Nada de errado aconteceu, basta ler 0 caracteres. O método readLine é um assassino de desempenho horrível. Você deve criar um BufferedReader totalmente novo se realmente quiser usar o readLin e. No momento, não é seguro para threads. Se alguém chamar uma operação enquanto o readLines estiver aguardando uma linha, ele produzirá resultados inesperados

Não gosto de retornar -2 onde estou. Eu lançaria uma exceção, porque algumas pessoas podem apenas verificar se int <0 deve considerar o EOS. De qualquer forma, esses métodos afirmam que "não pode bloquear", você deve verificar se essa afirmação é realmente verdadeira e simplesmente não a substitui.

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");
    }

}