Quelle est la différence entre le Futur et le FutureTask en Java?

En fait, vous avez raison. Les deux approches sont identiques. En général, vous n'avez pas besoin d'emballer vous-même. Si vous êtes, vous êtes susceptible de dupliquer le code dans AbstractExecutorService:

/**
 * Returns a <tt>RunnableFuture</tt> for the given callable task.
 *
 * @param callable the callable task being wrapped
 * @return a <tt>RunnableFuture</tt> which when run will call the
 * underlying callable and which, as a <tt>Future</tt>, will yield
 * the callable's result as its result and provide for
 * cancellation of the underlying task.
 * @since 1.6
 */
protected <T> RunnableFuture<T> newTaskFor(Callable<T> callable) {
    return new FutureTask<T>(callable);
}

La seule différence entre le Futur et le RunnableFuture, est la méthode run ():

/**
 * A {@link Future} that is {@link Runnable}. Successful execution of
 * the <tt>run</tt> method causes completion of the <tt>Future</tt>
 * and allows access to its results.
 * @see FutureTask
 * @see Executor
 * @since 1.6
 * @author Doug Lea
 * @param <V> The result type returned by this Future's <tt>get</tt> method
 */
public interface RunnableFuture<V> extends Runnable, Future<V> {
    /**
     * Sets this Future to the result of its computation
     * unless it has been cancelled.
     */
    void run();
}

Une bonne raison pour laisser l'Exécuteur construire le FutureTask pour vous est de s'assurer qu'il n'est pas possible de plus d'une référence à l'FutureTask instance. C'est, à l'Exécuteur testamentaire possède cette instance.

Future est juste l'interface. Derrière la scène, de la mise en œuvre est FutureTask.

Vous pouvez utiliser absolument FutureTask manuellement, mais vous perdrez les avantages de l'utilisation de Executor (mise en commun de thread, de limiter le fil, etc). À l'aide de FutureTask est assez similaire à l'aide de l'ancien Thread et à l'aide de la exécuter méthode.

En tant que Marque, et les autres, répondu que Future est l'interface pour FutureTask et Executor efficacement de son usine, ce qui signifie que le code de l'application rarement instancie FutureTask directement. Pour compléter la discussion, je fournis un exemple montrant une situation où FutureTask est construit et utilisé directement, en dehors de toute Executor:

    FutureTask<Integer> task = new FutureTask<Integer>(()-> {
        System.out.println("Pretend that something complicated is computed");
        Thread.sleep(1000);
        return 42;
    });

    Thread t1 = new Thread(()->{
        try {
            int r = task.get();
            System.out.println("Result is " + r);
        } catch (InterruptedException | ExecutionException e) {}
    });
    Thread t2 = new Thread(()->{
        try {
            int r = task.get();
            System.out.println("Result is " + r);
        } catch (InterruptedException | ExecutionException e) {}
    });
    Thread t3 = new Thread(()->{
        try {
            int r = task.get();
            System.out.println("Result is " + r);
        } catch (InterruptedException | ExecutionException e) {}
    });

    System.out.println("Several threads are going to wait until computations is ready");
    t1.start();
    t2.start();
    t3.start();
    task.run(); //let the main thread to compute the value

Ici, FutureTask est utilisé comme un outil de synchronisation, comme CountdownLatch ou similaire barrière primitive. Il pourrait avoir été re-mises en œuvre par l'aide de CountdownLatch ou des serrures et des conditions; FutureTask il fait juste bien encapsulée, auto-explicatif, élégant et avec moins de code.

Également noter que FutureTask#méthode run() doit être appelée explicitement, dans l'un des threads; il n'y pas d'Exécuteur testamentaire autour de le faire pour vous. Dans mon code, il est finalement exécutée par le thread principal, mais on peut modifier get() méthode à appeler run() sur le premier thread appelant get(), donc le premier thread atteindre get(), et il peut être tout de T1, T2 ou T3, serait de faire le calcul pour tous les autres threads.

Sur cette idée - premier thread demandant résultat serait de faire le calcul pour les autres, tandis que les tentatives simultanées serait bloqué, est fondée Memoizer, voir Memoizer Cache exemple à partir de la page 108 dans "la Java de la Simultanéité dans la Pratique".