throwsIOException + tryCatch

Olá spiderman,

Bem sua questão está em torno da regra do que chamamos de handel or declare.
na verdade essa operação de leitura de bytes é caracterizada como de risco, por isso ela lança uma exception do tipo IOException (Exception verificada).
Sendo assim vc é obrigado a declarar na assinatura do método que vc vai lançar essa Exception( passar a vez para quem chamou esse método) ou tratar a exception utilizando um bloco try catch.

Eu prefiro tratar a exception pois mais cedo ou mais tarde vc vai ter que capturar mesmo a exception ou seu programa pode fechar, causando um transtorno ao usuario.
Nesse caso utilize um bloco try catch:

# # private ByteBuffer blockRead(int bytes){    
# #     ByteBuffer msg = ByteBuffer.allocate(bytes);    
# #     int readBytes = 0;    
# #     while (readBytes < bytes) {   
##             try{ 
##
# #             int readCount = clientChannel.read(msg);  
# #             readBytes += readCount;     
##              if (readCount == -1) ;

##            } catch(IOException e){ 
# #                 System.out.println("OOps!! lançou IOException!");
##    
# #         } finally{
# #             System.out.println("FECHEI CONEXAO");    
# #             clientChannel.close();
# #         }    
# #      msg.flip();    
# #     
# #     return msg;    
# # }

A regra é sempre capturar as exceptions verificadas antes que cause um dano maior no sistema.
Quanto mais específica for o tipo da exception capturada, melhor fica sua aplicação, e menos recursos são utilizados pelo seu sistema.

Meu ponto de vista é esse, espero que sirva de ajuda.

Abraço

É longo, mas vale a pena ler:

http://blog.caelum.com.br/2006/10/07/lidando-com-exceptions/

Mas você tem que pensar assim. Se uma exception de I/O for disparada no meio do blockread, o que significa? Provalmente que o socket fechou, e que o canal não está mais disponível.

O blockread roda num loop. Uma exception dessa deveria parar o loop. Se você põe um try catch aí dentro, o seu loop vai tentar o tempo ler um canal indisponível, e vai ficar ininterruptamente procurando por um dado que nunca mais chegará lá. O canal avisa isso por uma exception, mas seu try catch a captura e ignora, o que faz a leitura ocorrer novamente.

E isso explica os tais 100% de CPU.