Эккель Брюс
Шрифт:
d.isDaemonO = true, DaemonSpawn 0 started, DaemonSpawn 1 started. DaemonSpawn 2 started. DaemonSpawn 3 started. DaemonSpawn 4 started. DaemonSpawn 5 started. DaemonSpawn 6 started, DaemonSpawn 7 started, DaemonSpawn 8 started. DaemonSpawn 9 started. t[0].isDaemonO = true. t[l] isDaemonO = true, t[2].isDaemonO = true, t[3].isDaemonO = true. t[4].isDaemonO = true. t[5].isDaemonO = true. t[6].isDaemonO = true. t[7].isDaemonO = true. t[8].isDaemonO = true. t[9].isDaemonO = true. *///:-
Поток Daemon переводится в режим демона, а затем порождает группу новых потоков, которые явно не назначаются демонами, но при этом все равно оказываются ими. Затем Daemon входит в бесконечный цикл, на каждом шаге которого вызывается метод yield, передающий управление другими процессам.
Учтите, что потоки-демоны завершают свои методы run без выполнения секций finally:
//: concurrency/DaemonsDontRunFinally.java
// Потоки-демоны не выполняют секцию finally.
import java.util.concurrent.*.
import static net.mindview.util.Print.*,
class ADaemon implements Runnable { public void run { try {
print("Запускаем ADaemon"); TimeUnit.SECONDS.sieep(l). } catch(InterruptedException e) {
print("Выход через InterruptedException"); } finally {
print("Должно выполняться всегда?");
}
}
}
public class DaemonsDontRunFinally {
public static void main(String[] args) throws Exception { Thread t = new Thread(new ADaemonO); t.setDaemon(true). t.startO,
}
} /* Output;
Запускаем ADaemon
*///:-
Запуск программы наглядно показывает, что секция finally не выполняется. С другой стороны, если закомментировать вызов setDaemon, вы увидите, что секция finally была выполнена.
Такое поведение верно, даже если из предыдущих описаний finally у вас сложилось обратное впечатление. Демоны завершаются «внезапно», при завершении последнего не-демона. Таким образом, сразу же при выходе из main JVM немедленно прерывает работу всех демонов, не соблюдая никакие формальности. Невозможность корректного завершения демонов ограничивает возможности их применения. Обычно объекты Executor оказываются более удачным решением, потому что все задачи, находящиеся под управлением Executor, могут быть завершены одновременно.
Варианты кодирования
Во всех предшествующих примерах все классы задач реализовали интерфейс Runnable. В очень простых случаях можно использовать альтернативное решение с прямым наследованием от Thread:
//• concurrency/SimpleThread.java // Прямое наследование от класса Thread.
public class SimpleThread extends Thread { private int countDown = 5; private static int threadCount = 0. public SimpleThreadO {
// Сохранение имени потока
super(Integer.toStri ng(++threadCount)).
startO.
}
public String toStringO {
return "#" + getNameO + "(" + countDown + "), ";
}
public void run {
while(true) {
System out print(this). if(--countDown == 0) return,
}
}
public static void main(String[] args) { for(int i = 0, i < 5, i++) new SimpleThreadO.
}
} /* Output
#1(5). #1(4). #1(3). #1(2). #1(1). #2(5). #2(4). #2(3). #2(2). #2(1). #3(5). #3(4). #3(3). #3(2). #3(1). #4(5). #4(4), #4(3). #4(2). #4(1). #5(5). #5(4). #5(3). #5(2). #5(1).
Чтобы задать объектам Thread имена, вы вызываете соответствующий конструктор Thread. Имя читается в методе toStringO при помощи getName.
Также иногда встречается идиома самоуправляемой реализации Runnable:
// concurrency/SelfManaged.java
// Реализация Runnable. содержащая собственый объект Thread
public class SelfManaged implements Runnable { private int countDown = 5. private Thread t = new Thread(this). public SelfManagedO { t startO. } public String toStringO {
return Thread currentThreadO .getNameO + "(" + countDown + "). ";
}
public void run {
while(true) {
System out print(this). if(--countDown == 0) return.
}
}
public static void main(Stnng[] args) { for(int i = 0. i < 5. i++) new SelfManagedO,
}
Thread-0(5) Thread-1(4) Thread-2(3) Thread-3(2) Thread-4(1) */// ~
В целом происходящее не так уж сильно отличается от наследования от Thread, разве что синтаксис получается чуть более громоздким. Однако реализация интерфейса позволяет наследовать от другого класса, тогда как в варианте с Thread это невозможно.
Обратите внимание на вызов start в конструкторе. Приведенный пример очень прост, поэтому, скорее всего, в нем такое решение безопасно, но вы должны знать, что запуск потоков в конструкторе может создать изрядные проблемы — до завершения конструктора может быть запущена на выполнение другая задача, которая обратится к объекту в нестабильном состоянии. Это еще одна причина, по которой использование Executor предпочтительнее явного создания объектов Thread.
Иногда бывает разумно спрятать потоковый код внутри класса с помощью внутреннего класса, как показано здесь: