Future.get()是Thread.join()的替代品吗？

我想写一个永远运行的命令行守护进程.我知道如果我希望JVM能够在linux中正常关闭,那么需要通过一些C代码来包装引导程序.我想我现在可以使用关机钩子了.

关于我的问题:

我的main(String [])块将触发一个单独的Superdaemon.

Superdaemon将永远轮询和循环.

通常我会这样做:

class Superdaemon extends Thread { ... }

class Bootstrap
{
    public static void main( String[] args )
    {
        Thread t = new Superdaemon();
        t.start();

        t.join();
    }
}

现在我想,如果我通过Executor启动Superdaemon,我可以做到

Future f = exec.submit( new Superdaemon() );

f.get();

是Future.get()与实现的Thread.join()？如果没有,它的行为是否相同？

问候,

阿席达卡

是的,你写这些的方式是等价的.

但是,您并不需要等待Superdaemon线程完成.当主线程完成执行main()时,该线程退出,但JVM不会.JVM将一直运行,直到最后一个非守护程序线程退出其run方法.

例如,

public class KeepRunning {
  public static void main(String[] args) {
    Superdaemon d = new Superdaemon();
    d.start();
    System.out.println(Thread.currentThread().getName() + ": leaving main()");
  }
}

class Superdaemon extends Thread {
  public void run() {
    System.out.println(Thread.currentThread().getName() + ": starting");
    try { Thread.sleep(2000); } catch(InterruptedException e) {}
    System.out.println(Thread.currentThread().getName() + ": completing");
  }
}

你会看到输出:

main: leaving main()
Thread-0: starting
Thread-0: completing

换句话说,主线程首先完成,然后辅助线程完成并且JVM退出.

问题是像JCIP这样的书籍主张我们使用Executors来启动Threads.所以我尽量不要使用Thread.start().我不确定我是否一定会基于简单性来选择一种特定的做事方式.必须有一个更令人信服的理由,不是吗？

使用java.util.concurrent的令人信服的理由是多线程编程非常棘手.Java为它提供了工具(Threads,synchronized和volatile关键字),但这并不意味着你可以直接安全地使用它们而不会让自己陷入困境:同步太多,导致不必要的瓶颈和死锁,或者太少,由于竞争条件导致不稳定的行为).

使用java.util.concurrent,您可以获得一组实用程序(由专家编写),用于最常见的使用模式,您可以使用它而不必担心您正确使用低级别的东西.

但是,在你的特殊情况下,我根本不明白为什么你需要一个单独的线程,你可能也会使用主线程:

public static void main( String[] args )
{
    Runnable t = new Superdaemon();
    t.run();
}

执行程序适用于您希望在后台运行的任务(当您有多个并行任务或当前线程可以继续执行其他操作时).