2016-03-31 5 views
0

Ich habe Socket für gelesen konfiguriert nur SelectionKey.OP_CONNECT | SelectionKey.OP_READ Profiler zeigt runChannel die CPU aufwändige Methode ist und eigentlich ist es sinnvoll, weil es unendliche Schleife ist die Methode aufruft selector.select() die ganze Zeit, aber auf der anderen Seite I haben Dutzende solcher Verbindungen und es tötet CPU.
Gibt es eine Möglichkeit, die CPU-Last zu verringern und gleichzeitig keine eingehende Nachricht zu verpassen?Socket hohe CPU-Last auf lesen

public void runChannel() { 
    while (session.isConnectionAlive()) { 
     try { 
      // Wait for an event 
      int num = selector.select(); 
      // If you don't have any activity, loop around and wait 
      // again. 
      if (num == 0) { 
       continue; 
      } 
     } catch (IOException e) { 
      log.error("Selector error: {}", e.toString()); 
      log.debug("Stacktrace: ", e); 
      session.closeConnection(); 
      break; 
     } 
     handleSelectorkeys(selector.selectedKeys()); 
    } 

}

+0

Schlaf (0) in der Schleife? – Tokazio

+0

Welche JRE- und OS-Version verwenden Sie? Weiter - diese Methode wird wo implementiert? Sie sollten nur eine einzige Thread-Selektorschleife haben. Ist es so? Werden alle Daten gelesen, wenn sie verfügbar sind? Gibt es Gründe dafür, dass Sie auf Connect warten und lesen? (Sie sollten nur das passende verwenden) – gusto2

+0

JRE 7, Ich habe versucht auf verschiedene Version von Windows (Server für prod, win7 für dev) – Diyko

Antwort

1

Unsunscribe von op_connect - wählen() nicht blockieren, wenn Sie op_connect abonniert haben und verbunden.

+1

Und dito OP_WRITE, die nur verwendet werden sollte, wenn Sie den Socket-Sendepuffer gefüllt haben und 'write()' hat Null zurückgegeben. – EJP