In quali condizioni il blocco Scanner.hasNextLine() di Java?

Question

Il Javadoc per Scanner.hasNextLine() stati:

Restituisce vero se c'è un'altra linea in ingresso di questo scanner. Questo metodo può blocco in attesa di input. Lo scanner fa non oltrepassare alcun input.

In quali condizioni il metodo bloccherà?

Answer 1

Dipende dalla sorgente da cui lo scanner riceve l'input.

Ad esempio, se si tratta di un file, l'intero input è disponibile, così hasNextLine() non sarebbe bloccare (poiché può sapere con certezza quando viene raggiunta la fine del file e non c'è alcun input.

On D'altra parte, se la sorgente è un input standard, può sempre esserci più input - l'utente può sempre digitare più input - quindi hasNextLine() bloccherebbe fino a quando l'utente digita una nuova riga di input.

Answer 2

Supponendo di se bloccherà " vuoi dire che vuoi sapere quando buggera '

Dai un'occhiata a dove l'ingresso è assegnato nel metodo hasNextLine

String result = findWithinHorizon(linePattern(), 0); 

Ora, date un'occhiata al findWithinHorizon metodo

public String findWithinHorizon(Pattern pattern, int horizon) { 
    ensureOpen(); 
    if (pattern == null) 
     throw new NullPointerException(); 
    if (horizon < 0) 
     throw new IllegalArgumentException("horizon < 0"); 
    clearCaches(); 

    // Search for the pattern 
    while (true) { //it may block here if it never break 
     String token = findPatternInBuffer(pattern, horizon); 
     if (token != null) { 
      matchValid = true; 
      return token; 
     } 
     if (needInput) 
      readInput(); 
     else 
      break; // up to end of input 
    } 
    return null; 
} 

Come si può vedere, è in loop all'infinito fino alla fine viene raggiunto, o fino a quando non riesce a leggere.

findPatternInBuffer è un metodo privato della classe Scanner che tenta di leggere l'input.

private String findPatternInBuffer(Pattern pattern, int horizon) { 
    matchValid = false; 
    matcher.usePattern(pattern); 
    int bufferLimit = buf.limit(); 
    int horizonLimit = -1; 
    int searchLimit = bufferLimit; 
    if (horizon > 0) { 
     horizonLimit = position + horizon; 
     if (horizonLimit < bufferLimit) 
      searchLimit = horizonLimit; 
    } 
    matcher.region(position, searchLimit); 
    if (matcher.find()) { 
     if (matcher.hitEnd() && (!sourceClosed)) { 
      // The match may be longer if didn't hit horizon or real end 
      if (searchLimit != horizonLimit) { 
       // Hit an artificial end; try to extend the match 
       needInput = true; 
       return null; 
      } 
      // The match could go away depending on what is next 
      if ((searchLimit == horizonLimit) && matcher.requireEnd()) { 
       // Rare case: we hit the end of input and it happens 
       // that it is at the horizon and the end of input is 
       // required for the match. 
       needInput = true; 
       return null; 
      } 
     } 
     // Did not hit end, or hit real end, or hit horizon 
     position = matcher.end(); 
     return matcher.group(); 
    } 

    if (sourceClosed) 
     return null; 

    // If there is no specified horizon, or if we have not searched 
    // to the specified horizon yet, get more input 
    if ((horizon == 0) || (searchLimit != horizonLimit)) 
     needInput = true; 
    return null; 
} 

ho postato l'intero metodo per darvi una migliore idea di quello che volevo dire da "riescono a leggere".

Answer 3

Come decidere se bloccherà?

Per decidere se bloccare o meno hasNextLine non è un caso di utilizzo supportato.

Questo perché le origini sottostanti non forniscono sempre un'API per sbirciare nello stream. In altre parole, l'implementazione di hasNextLine chiama metodi che possono essere bloccati da soli, quindi il problema è in qualche modo inerente.

---

Quindi, cosa fare?

Se questo è davvero un caso d'uso richiesto, mi sento di raccomandare uno dei seguenti approcci:

• Assicurarsi che ci sono le condizioni per l'hasNextLine. Fornire allo scanner solo sorgenti con una fine definita (come un file o una stringa) e mai un input "aperto" come System.in.

  Se questo fa parte di un'API, è possibile avvolgere lo scanner nella propria classe che espone solo costruttori "sicuri".

• Arrotolare la propria classe da zero che ha un tipo di metodo willHasNextLineBlock. Questo potrebbe probabilmente essere implementato in modo piuttosto robusto utilizzando InputStream.available.

---

Sotto la categoria di super brutti soluzioni troviamo:

• Fare un tentativo di chiamare hasNextLine in un thread separato e vedere se restituisce entro un tempo ragionevole, come segue:

  boolean wouldBlock = false; 
  Thread t = new Thread(() -> s.hasNextLine()); 
  t.start(); 
  try { 
      t.join(100); 
  } catch (InterruptedException e) { 
      wouldBlock = true; 
  } 
  

• Utilizzare un flusso di input personalizzato (cosa come uno peekable stream che si potrebbe attingere prima di chiamare hasNextLine. Qualcosa di simile al questo

  CustomStream wrapped = new CustomStream(originalSource) 
  Scanner s = new Scanner(wrapped); 
  ... 
  if (wrapped.hasNextLine()) 
      // s.hasNextLine would not block 
  else 
      // s.hasNextLine would block 
  

  (Si noti, tuttavia, che questo è un po pericoloso, dal momento che lo scanner può aver tamponato alcuni dati dal CustomStream.)