De acordo com a API Java, oInputStream.read() é descrito como:

Se nenhum byte estiver disponível porque o final do fluxo foi atingido, o valor -1 será retornado. Esse método é bloqueado até que os dados de entrada estejam disponíveis, o final do fluxo seja detectado ou uma exceção seja lançad

Eu tenho umwhile(true) loop fazendo uma leitura e sempre recebo -1 quando nada é enviado pelo fluxo. Isso é esperado.

Minha pergunta é quando é que ler () sempre bloquear? Como se não obtiver nenhum dado, ele retornará -1. Eu esperaria que uma leitura de bloqueio esperasse até os dados serem recebidos. Se você chegou ao final do fluxo de entrada, não deve ler () simplesmente esperar pelos dados em vez de retornar -1?

O read () só bloqueia se houver outro encadeamento acessando o fluxo e o seu read () não puder acessar o fluxo?

Que me leva à minha próxima pergunta. Eu costumava ter um ouvinte de eventos (fornecido pela minha biblioteca) que me notificava quando os dados estavam disponíveis. Quando fui notificado, ligava parawhile((aByte = read()) > -1) armazena o byte. Fiquei intrigado quando recebi DOIS eventos em um tempo muito próximo e nem todos os meus dados estavam sendo exibidos. Parecia que apenas o final dos dados do segundo evento seria exibido e o restante estava faltand

Eu mudei meu código para que, quando eu recebesse um evento, chamasseif(inputStream.available() > 0) while((aByte = read()) > -1) armazena o byte. Agora funcionou corretamente e todos os meus dados foram exibido

Alguém pode explicar esse comportamento? OInputStream.available()iz-se que @ retorna o número de bytes que você pode ler antes de bloquear o próximo chamador (do fluxo?). Mesmo se eu não usar .available (), seria de esperar que a leitura do primeiro evento bloqueie a leitura do segundo evento, mas não apague ou consuma muitos dados de fluxo. Por que isso faria com que nem todos os meus dados fossem exibidos?