Chiamata di metodo ai blocchi Future.get(). È davvero desiderabile?

Question

Leggere attentamente la domanda prima di contrassegnarla come duplicata.

Di seguito è riportato lo snippet dello pseudo codice. La mia domanda è: il codice seguente non sconfigge la nozione stessa di elaborazione parallela asincrona?

Il motivo per cui lo chiedo è perché nel codice sottostante il thread principale dovrebbe inviare un'attività da eseguire in un thread diverso. Dopo aver inviato l'attività in coda, blocca il metodo Future.get() affinché l'attività restituisca il valore. Preferirei che l'attività fosse eseguita nella discussione principale anziché inviarla a un thread diverso e attendere i risultati. Che cosa ho ottenuto eseguendo l'attività in una nuova discussione?

Sono consapevole che è possibile attendere un tempo limitato, ecc., Ma che succede se mi interessa davvero del risultato? Il problema peggiora se ci sono più attività da eseguire. Mi sembra che stiamo semplicemente facendo il lavoro in modo sincrono. Sono a conoscenza della libreria Guava che fornisce un'interfaccia listener non bloccante. Ma sono interessato a sapere se la mia comprensione è corretta per l'API Future.get(). Se è corretto, perché il Future.get() è progettato per bloccare e quindi sconfiggere l'intero processo di elaborazione parallela?

Nota - Per la cronaca, io uso JAVA 6

public static void main(String[] args){ 

private ExectorService executorService = ... 

Future future = executorService.submit(new Callable(){ 
    public Object call() throws Exception { 
     System.out.println("Asynchronous Callable"); 
     return "Callable Result"; 
    } 
}); 

System.out.println("future.get() = " + future.get()); 
} 

Answer 1

Future vi offre il metodo isDone() che non blocca e restituisce vero se il calcolo è stato completato, altrimenti false.

Future.get() viene utilizzato per recuperare il risultato del calcolo.

Hai un paio di opzioni:

• chiamata isDone() e se il risultato è pronto chiedere esso invocando get(), notare come non v'è alcun blocco
• blocco a tempo indeterminato con get()
• blocco per timeout specificato con get(long timeout, TimeUnit unit)

L'intera cosa Future API è lì per h come ottenere facilmente i valori dai thread che eseguono attività parallele. Questo può essere fatto in modo sincrono o asincrono se preferisci, come descritto nei punti sopra.

AGGIORNAMENTO CON CACHE ESEMPIO

Ecco un'implementazione della cache dalla Java Concurrency in Practice, un caso eccellente utilizzazione Future.

• Se il calcolo è già in esecuzione, chiamante interessati a seguito di calcolo attenderà per il calcolo finisca
• Se il risultato è pronto nella cache, chiamante lo ritirerà
• se il risultato non è pronto e il calcolo non è ancora iniziato, il chiamante inizierà il calcolo e avvolgerà i risultati in Future per altri chiamanti.

Tutto ciò è facilmente raggiungibile con l'API Future.

package net.jcip.examples; 

import java.util.concurrent.*; 
/** 
* Memoizer 
* <p/> 
* Final implementation of Memoizer 
* 
* @author Brian Goetz and Tim Peierls 
*/ 
public class Memoizer <A, V> implements Computable<A, V> { 
    private final ConcurrentMap<A, Future<V>> cache 
      = new ConcurrentHashMap<A, Future<V>>(); 
    private final Computable<A, V> c; 

public Memoizer(Computable<A, V> c) { 
    this.c = c; 
} 

public V compute(final A arg) throws InterruptedException { 
    while (true) { 

     Future<V> f = cache.get(arg); 
     // computation not started 
     if (f == null) { 
      Callable<V> eval = new Callable<V>() { 
       public V call() throws InterruptedException { 
        return c.compute(arg); 
       } 
      }; 

      FutureTask<V> ft = new FutureTask<V>(eval); 
      f = cache.putIfAbsent(arg, ft); 
      // start computation if it's not started in the meantime 
      if (f == null) { 
       f = ft; 
       ft.run(); 
      } 
     } 

     // get result if ready, otherwise block and wait 
     try { 
      return f.get(); 
     } catch (CancellationException e) { 
      cache.remove(arg, f); 
     } catch (ExecutionException e) { 
      throw LaunderThrowable.launderThrowable(e.getCause()); 
     } 
    } 
    } 
} 

Answer 2

Nell'esempio hai dato si potrebbe anche eseguire tutto nel metodo main() e andare il tuo modo allegro.

Ma supponiamo di avere tre fasi di calcolo che stai correntemente eseguendo in sequenza. Giusto per capire supponiamo che step1 impieghi t1 secondi, step2 impieghi t2 secondi e step3 impieghi t3 secondi per completarsi. Quindi il tempo totale di calcolo è t1+t2+t3. Supponiamo inoltre che t2>t1>=t3.

Consideriamo ora uno scenario quando eseguiamo questi tre passaggi in parallelo usando Future per contenere tutti i risultati di calcolo. È possibile verificare se ciascuna attività viene eseguita utilizzando la chiamata isDone() non bloccante sui future corrispondenti. Ora cosa succede? in teoria la tua esecuzione è veloce come quella che t2 completa correttamente? Quindi noi ha ottenuto alcuni vantaggi dal parallelismo.

Inoltre, in Java8, è disponibile il CompletableFuture che supporta i richiami di stile funzionale.

Answer 3

Se non si cura dei risultati, generare un nuovo thread e da tale thread utilizzare l'API ExectorService per l'invio dell'attività. In questo modo, il thread padre, cioè il thread main, non bloccherà in alcun modo, genererebbe semplicemente un nuovo thread e quindi avvierà un'ulteriore esecuzione, mentre il nuovo thread invierà le tue attività.

Per creare un nuovo thread: esegui da solo un ThreadFactory per la creazione di thread asincrona o utilizza un'implementazione di java.util.concurrent.Executor.

Se questo è in un'applicazione JEE e si utilizza il framework Spring, è possibile creare facilmente un nuovo thread asincrono utilizzando l'annotazione @async.

Spero che questo aiuti!

Answer 4

Di seguito è riportato lo snippet dello pseudo codice. La mia domanda è: il codice seguente non sconfigge la nozione stessa di elaborazione parallela asincrona?

Tutto dipende dal vostro caso d'uso:

1. Se davvero si vuole bloccare fino ad ottenere il risultato, l'uso bloccando get()
2. Se si può aspettare per un determinato periodo per conoscere lo stato invece di una durata di blocco infinita, utilizzare con timeout

3. Se è possibile continuare senza analizzare immediatamente il risultato e ispezionare il risultato in futuro, utilizzare CompletableFuture

   Un Futuro che può essere completato in modo esplicito (impostandone il valore e lo stato) e può essere utilizzato come CompletionStage, supportando funzioni dipendenti e azioni che si attivano al suo completamento.

4. È possibile implementare il meccanismo di callback da Runnable/Callable. Date un'occhiata al di sotto SE domanda:

   Java executors: how to be notified, without blocking, when a task completes?