Класс Thread
В классе Thread семь конструкторов:
Thread(ThreadGroup group, Runnabie target, String name) — создает ПОД-процесс с именем name, принадлежащий группе group и выполняющий метод run о объекта target. Это основной конструктор, все остальные обращаются к нему с тем или иным параметром, равным null; Thread () — создаваемый подпроцесс будет выполнять свой метод run ();Thread(Runnabie target); Thread(Runnabie target, String name); Thread(String name); Thread(ThreadGroup group, Runnabie target); Thread(ThreadGroup group, String name).
Имя подпроцесса name не имеет никакого значения, оно не используется, виртуальной машиной Java и применяется только для различения подпроцессов в программе.
После создания подпроцесса его надо запустить методом start (). Виртуальная машина Java начнет выполнять метод run () этого объекта-подпроцесса.
Подпроцесс завершит работу после выполнения метода run (). Для уничтожения объекта-подпроцесса вслед за этим он должен присвоить значение null.
Выполняющийся подпроцесс можно приостановить статическим методом sleep (long ms) на ms миллисекунд. Этот метод мы уже использовали в предыдущих главах. Если вычислительная система может отсчитывать наносекунды, то можно приостановить подпроцесс с точностью до наносекунд методом sleep(long ms, int nanosec).
В листинге 17.1 приведен простейший пример. Главный подпроцесс создает два подпроцесса с именами Thread i и Thread 2, выполняющих один и тот же метод run (). Этот метод просто выводит 20 раз текст на экран, а затем сообщает о своем завершении.
Листинг 17.1. Два подпроцесса, запущенных из главного подпроцесса
class OutThread extends Thread{
private String msg;
OutThread(String s, String name){
super(name); msg = s;
}
public void run()
{
for(int i = 0; i < 20; i++){
// try{
// Thread.sleep(100);
// }catch(InterruptedException ie){}
System.out.print(msg + " ");
}
System.out.println("End of " + getName());
}
} class TwoThreads{
public static void main(String[] args){
new OutThread("HIP", "Thread 1").start();
new OutThread("hop", "Thread 2").start();
System.out.println();
}
}
На рис. 17.1 показан результат двух запусков программы листинга 17.1. Как видите, в первом случае подпроцесс Thread i успел отработать полностью до переключения процессора на выполнение второго подпроцесса. Во втором случае работа подпроцесса Thread i была прервана, процессор переключился на выполнение подпроцесса Thread 2, успел выполнить его полностью, а затем переключился обратно на выполнение подпроцесса Thread i и завершил его.
Рис. 17.1. Два подпроцесса работают без задержки
Уберем в листинге 17.1 комментарии, задержав тем самым выполнение каждой итерации цикла на 0,1 секунды. Пустая обработка исключения InterruptedException означает, что мы игнорируем попытку прерывания работы подпроцесса. На рис. 17.2 показан результат двух запусков программы. Как видите, процессор переключается с одного подпроцесса на другой, но в одном месте регулярность переключения нарушается и ранее запущенный подпроцесс завершается позднее.
Рис. 17.2. Подпроцессы работают с задержкой
Как же добиться согласованности, как говорят, синхронизации (synchronization) подпроцессов? Обсудим это ниже, а пока покажем еще два варианта создания той же самой программы.
В листинге 17.2 приведен второй вариант той же программы: сам класс TwoThreads2 является расширением класса Thread, а метод run () реализуется прямо в нем.
Листинг 17.2. Класс расширяет Thread
class TwoThreads2 extends Thread{
private String msg;
TwoThreads2(String s, String name){
super(name); msg = s;
}
public void run(){
for(int i = 0; i < 20; i++){
try{
Thread.sleep(100);
}catch(InterruptedException ie){}
System.out.print(msg + " ");
}
System.out.println("End of " + getName());
}
public static void main(String[] args)(
new TwoThreads2("HIP", "Thread 1").start();
new TwoThreads2("hop", "Thread 2").start();
System.out.println();
}
}
Третий вариант: класс TwoThreads3 реализует интерфейс Runnabie. Этот вариант записан в листинге 17.3. Здесь нельзя использовать методы класса Thread, но зато класс TwoThreads3 может быть расширением другого класса. Например, можно сделать его апплетом, расширив класс Applet или JAppiet.
Листинг 17.3. Реализация интерфейса Runnabie
class TwoThreadsS implements Runnabie{
private String msg;
TwoThreads3(String s){ msg = s; }
public void run(){
forfint i = 0; i < 20; i++){
try{
Thread.sleep(100);
}catch(InterruptedException ie){}
System.out.print(msg + " ");
}
System.out.println("End of thread.");
}
public static void main (String[] args){
new Thread(new TwoThreads3("HIP"), "Thread 1").start ();
new Thread(new TwoThreads3("hop"), "Thread 2").start ();
System.out.println();
}
}
Чаще всего в новом подпроцессе задаются бесконечные действия, выполняющиеся на фоне основных действий: проигрывается музыка, на экране вращается анимированный логотип фирмы, бежит рекламная строка. Для реализации такого подпроцесса в методе run о задается бесконечный цикл, останавливаемый после того, как объект-подпроцесс получит значение null.
В листинге 17.4 показан четвертый вариант той же самой программы, в которой метод runt) выполняется до тех пор, пока текущий объект-подпроцесс th совпадает с объектом до, запустившим текущий подпроцесс. Для прекращения его выполнения предусмотрен метод stop (), к которому обращается главный подпроцесс. Это стандартная конструкция, рекомендуемая документацией J2SDK. Главный подпроцесс в данном примере только создает объекты-подпроцессы, ждет одну секунду и останавливает их.
Листинг 17.4. Прекращение работы подпроцессов
class TwoThreadsS implements Runnabie{
private String msg;
private Thread go;
TwoThreadsS(String s){
msg = s;
go = new Thread(this);
go.start();
}
public void run(){
Thread th = Thread.currentThread();
while(go == th){
try{
Thread.sleep(100);
}catch(InterruptedException ie){}
System.out.print(msg + " ");
}
System.out.println("End of thread.");
}
public void stop(){ go = null; }
public static void main(String[] args){
TwoThreadsS thl = new TwoThreadsS("HIP");
TwoThreadsS th2 = new TwoThreadsS("hop");
try{
Thread.sleep(1000);
}catch(InterruptedException ie){}
thl.stop(); th2.stop();
System.out.printlnf);
}
}
Синхронизация подпроцессов
Основная сложность при написании программ, в которых работают несколько подпроцессов — это согласовать совместную работу подпроцессов с общими ячейками памяти.
Классический пример — банковская транзакция, в которой изменяется остаток на счету клиента с номером numDep. Предположим, что для ее выполнения запрограммированы такие действия:
Deposit myDep = getDeposit(numDep); // Получаем счет с номером numDep
int rest = myDep.getRest(); // Получаем остаток на счету myDep
Deposit newDep = myDep.operate(rest, sum); // Изменяем остаток
// на величину sum
myDep.setDeposit(newDep); // Заносим новый остаток на счет myDep
Пусть на счету лежит 1000 рублей. Мы решили снять со счета 500 рублей, а в это же время поступил почтовый перевод на 1500 рублей. Эти действия выполняют разные подпроцессы, но изменяют они один и тот же счет myDep с номером numDep. Посмотрев еще раз на рис. 17.1 и 17.2, вы поверите, что последовательность действий может сложиться так. Первый подпроцесс проделает вычитание 1000-500, в это время второй подпроцесс выполнит все три действия и запишет на счет 1000+1500 = 2500 рублей, после чего первый подпроцесс выполнит свое последнее действие и у нас на счету окажется 500 рублей. Вряд ли вам понравится такое выполнение двух транзакций.
В языке Java принят выход из этого положения, называемый в теории операционных систем монитором (monitor). Он заключается в том, что подпроцесс блокирует объект, с которым работает, чтобы другие подпроцессы не могли обратиться к данному объекту, пока блокировка не будет снята. В нашем примере первый подпроцесс должен вначале заблокировать счет myDep, затем полностью выполнить всю транзакцию и снять блокировку. Второй подпроцесс приостановится и станет ждать, пока блокировка не будет снята, после чего начнет работать с объектом myDep.
Все это делается одним оператором synchronized () {}, как показано ниже:
Deposit myDep = getDeposit(numDep); synchronized(myDep){
int rest = myDep.getRest();
Deposit newDep = myDep.operate(rest, sum);
myDep.setDeposit(newDep);
}
В заголовке оператора synchronized в скобках указывается ссылка на объект, который будет заблокирован перед выполнением блока. Объект будет недоступен для других подпроцессов, пока выполняется блок. После выполнения блока блокировка снимается.
Если при написании какого-нибудь метода оказалось, что в блок synchronized входят все операторы этого метода, то можно просто пометить метод-словом synchronized, сделав его синхронизированным (synchronized):
synchronized int getRest()(
// Тело метода
}
synchronized Deposit operate(int rest, int sum) {
// Тело метода
}
synchronized void setDeposit(Deposit dep){
// Тело метода
}
В этом случае блокируется объект, выполняющий метод, т. е. this. Если все методы, к которым не должны одновременно обращаться несколько подпроцессов, помечены synchronized, то оператор synchronized () (} уже не нужен. Теперь, если один подпроцесс выполняет синхронизированный метод объекта, то другие подпроцессы уже не могут обратиться ни к одному синхронизированному методу того же самого объекта.
Приведем простейший пример. Метод run о в листинге 17.5 выводит строку "Hello, World!" с задержкой в 1 секунду между словами. Этот метод выполняется двумя подпроцессами, работающими с одним объектом th. Программа выполняется два раза. Первый раз метод run () не синхронизирован, второй раз синхронизирован, его заголовок показан в листинге 17.4 как комментарий. Результат выполнения программы представлен на рис. 17.3.
Листинг 17.5. Синхронизация метода
class TwoThreads4 implements Runnable{
public void run(){
// synchronized public void run(){
System.out.print("Hello, ");
try{
Thread.sleep(1000);
}catch(InterruptedException ie){}
System.out.println("World!");
}
public static void main(String[] args){
TwoThreads4 th = new TwoThreads4();
new Thread(th).start();
new Thread(th).start();
}
}
Рис. 17.3. Синхронизация метода
Действия, входящие в синхронизированный блок или метод образуют критический участок (critical section) программы. Несколько подпроцессов, собирающихся выполнять критический участок, встают в очередь. Это замедляет работу программы, поэтому для быстроты ее выполнения критических участков должно быть как можно меньше, и они должны быть как можно короче.
Многие методы Java 2 SDK синхронизированы. Обратите внимание, что на рис. 17.1 слова выводятся вперемешку, но каждое слово выводится полностью. Это происходит потому, что метод print о класса Printstream синхронизирован, при его выполнении выходной поток system, out блокируется до тех пор, пока метод print () не закончит свою работу.
Итак, мы можем легко организовать последовательный доступ нескольких подпроцессов к полям одного объекта с помощью оператора synchronized () {}. Синхронизация обеспечивает взаимно исключающее (mutually exclusive) выполнение подпроцессов. Но что делать, если нужен совместный доступ нескольких подпроцессов к общим объектам? Для этого в Java существует механизм ожидания и уведомления (wait-notify).
Согласование работы нескольких подпроцессов
Возможность создания многопоточных программ заложена в язык Java с самого его создания. В каждом объекте есть три метода wait о и один метод notify о, позволяющие приостановить работу подпроцесса с этим объектом, позволить другому подпроцессу поработать с объектом, а затем уведомить (notify) первый подпроцесс о возможности продолжения работы. Эти методы определены прямо в классе object и наследуются всеми классами.
С каждым объектом связано множество подпроцессов, ожидающих доступа к объекту (wait set). Вначале этот "зал ожидания" пуст.
Основной метод wait (long miiiisec) приостанавливает текущий подпроцесс this, работающий с объектом, на miiiisec миллисекунд и переводит его в "зал ожидания", в множество ожидающих подпроцессов. Обращение к этому методу допускается только в синхронизированном блоке или методе, чтобы быть уверенными в том, что с объектом работает только один подпроцесс. По истечении miiiisec или после того, как объект получит уведомление методом notify о, подпроцесс готов возобновить работу. Если аргумент miiiisec равен о, то время ожидания не определено и возобновление работы подпроцесса возможно только после того, как объект получит уведомление методом notify().
Отличие данного метода от метода sleep о в том, что метод wait о снимает блокировку с объекта. С объектом может работать один из подпроцессов из "зала ожидания", обычно тот, который ждал дольше всех, хотя это не гарантируется спецификацией JLS.
Второй метод wait () эквивалентен wait (0). Третий метод wait (long millisec, int nanosec) уточняет задержку на nanosec наносекунд, если их сумеет отсчитать операционная система.
Метод notify () выводит из "зала ожидания" только один, произвольно выбранный подпроцесс. Метод notifyAll() выводит из состояния ожидания все подпроцессы. Эти методы тоже должны выполняться в синхронизированном блоке или методе.
Как же применить все это для согласованного доступа к объекту? Как всегда, лучше всего объяснить это на примере.
Обратимся снова к схеме "поставщик-потребитель", уже использованной в главе 15. Один подпроцесс, поставщик, производит вычисления, другой, потребитель, ожидает результаты этих вычислений и использует их по мере поступления. Подпроцессы передают информацию через общий экземпляр st класса store.
Работа этих подпроцессов должна быть согласована. Потребитель обязан ждать, пока поставщик не занесет результат вычислений в объект st, а поставщик должен ждать, пока потребитель не возьмет этот результат.
Для простоты поставщик просто заносит в общий объект класса store целые числа, а потребитель лишь забирает их.
В листинге 17.6 класс store не обеспечивает согласования получения и выдачи информации. Результат работы показан на рис. 17.4.
Листинг 17.6. Несогласованные подпроцессы
class Store{
private inf inform;
synchronized public int getlnform(){ return inform; }
synchronized public void setlnform(int n){ inform = n; }
}
class Producer implements Runnable{
private Store st;
private Thread go;
Producer(Store st){
this.st = st;
go = new Thread(this);
go.start();
}
public void run(){
int n = 0;
Thread th = Thread.currentThread();
while(go == th){
st.setlnform(n);
System.out.print("Put: " + n + " ");
n++;
}
}
public void stop(){ go = null;
}
}
class Consumer implements Runnable{
private Store st;
private Thread go;
Consumer(Store st){
this.st = st;
go =-new Thread(this);
go.start () ;
}
public void run(){
Thread th = Thread.currentThread();
while(go == th) System.out.println("Got: " + st.getlnformf));
}
public void stop(){ go = null; }
}
class ProdCons{
public static void main(String[] args){
Store st = new Store();
Producer p = new Producer(st);
Consumer с = new Consumer(st);
try{
Thread.sleep(30);
}catch(InterruptedException ie){}
p.stop(); c.stop();
}
}
Рис. 17.4. Несогласованная работа двух подпроцессов
В листинге 17.7 в класс store внесено логическое поле ready, отмечающее процесс получения и выдачи информации. Когда новая порция информации получена от поставщика Producer, в поле ready заносится значение true, получатель consumer может забирать эту порцию информации. После выдачи информации переменная ready становится равной false.
Но этого мало. То, что получатель может забрать продукт, не означает, что он действительно заберет его. Поэтому в конце метода setinformf) получатель уведомляется о поступлении продукта методом notify о. Пока поле ready не примет нужное значение, подпроцесс переводится в "зал ожидания" методом wait (). Результат работы программы с обновленным классом store показан на рис. 17.5.
Листинг 17.7. Согласование получения и выдачи информации
class Store{
private int inform = -1;
private boolean ready;
synchronized public int getlnform(){
try{
if (! ready) wait();
ready = false;
return inform;
}catch(InterruptedException ie){
}finally!
notify();
}
return -1;
}
synchronized public void setlnform(int n)(
if (ready)
try{
wait ();
}catch(InterruptedException ie){}
inform = n;
ready = true;
notify();
}
}
Поскольку уведомление поставщика в методе getinformo должно происходить уже после отправки информации оператором return inform, оно включено В блок finally{}
Рис. 17.5. Согласованная работа подпроцессов
Обратите внимание: сообщение "Got: 0" отстает на один шаг от действительного получения информации.
Приоритеты подпроцессов
Планировщик подпроцессов виртуальной машины Java назначает каждому подпроцессу одинаковое время выполнения процессором, переключаясь с подпроцесса на подпроцесс по истечении этого времени. Иногда необходимо выделить какому-то подпроцессу больше или меньше времени по сравнению с другим подпроцессом. В таком случае можно задать подпроцессу больший или меньший приоритет.
В классе Thread есть три целые статические константы, задающие приоритеты:
NORM_PRIORITY — обычный приоритет, который получает каждый подпроцесс при запуске, его числовое значение 5; MIN_PRIORITY — наименьший приоритет, его значение 1; MAX_PRIORITY — наивысший приоритет, его значение 10.Кроме этих значений можно задать любое промежуточное значение от 1 до 10, но надо помнить о том, что процессор будет переключаться между подпроцессами с одинаковым высшим приоритетом, а подпроцессы с меньшим приоритетом не станут выполняться, если только не приостановлены все подпроцессы с высшим приоритетом. Поэтому для повышения общей производительности следует приостанавливать время от времени методом sleep о подпроцессы с высоким приоритетом.
Установить тот или иной приоритет можно в любое время методом setPriorityfint newPriority), если подпроцесс имеет право изменить свой приоритет. Проверить наличие такого права можно методом checkAtcess(). Этот метод выбрасывает исключение класса Security&xception, если подпроцесс не может изменить свой приоритет.
Порожденные подпроцессы будут иметь тот же приоритет, что и подпроцесс-родитель.
Итак, подпроцессы, как правило, должны работать с приоритетом NORM_PRIORITY . Подпроцессы, большую часть времени ожидающие наступления какого-нибудь события, например, нажатия пользователем кнопки Выход, могут получить более высокий приоритет MAX_PRIORITY . Подпроцессы, выполняющие длительную работу, например, установку сетевого соединения или отрисовку изображения в памяти при двойной буферизации, могут работать с низшим приоритетом MIN_PRIORITY .
Подпроцессы-демоны
Работа программы начинается с выполнения метода main о главным подпроцессом. Этот подпроцесс может породить другие подпроцессы, они, в свою очередь, способны породить свои подпроцессы. После этого главный подпроцесс ничем не будет отличаться от остальных подпроцессов. Он не следит за порожденными им подпроцессами, не ждет от них никаких сигналов. Главный подпроцесс может завершиться, а программа будет продолжать работу, пока не закончит работу последний подпроцесс.
Это правило не всегда удобно. Например, какой-то из подпроцессов может приостановиться, ожидая сетевого соединения, которое никак не может наступить. Пользователь, не дождавшись соединения, прекращает работу главного подпроцесса, но программа продолжает работать.
Такие случаи можно учесть, объявив некоторые подпроцессы демонами (daemons). Это понятие не совпадает с понятием демона в UNIX. Просто программа завершается по окончании работы последнего пользовательского (user) подпроцесса, не дожидаясь окончания работы демонов. Демоны будут принудительно завершены исполняющей системой Java.
Объявить подпроцесс демоном можно сразу после его создания, перед запуском. Это делается методом setoaemon(true). Данный метод обращается к методу checkAccess () И МОЖEТ выбросить SecurityException.
Изменить статус демона после запуска процесса уже нельзя.
Все подпроцессы, порожденные демоном, тоже будут демонами. Для изменения их статуса необходимо обратиться к методу setoaemon(false).
Группы подпроцессов
Подпроцессы объединяются в группы. В начале работы программы исполняющая система Java создает группу подпроцессов с именем main. Все подпроцессы по умолчанию попадают в эту группу.
В любое время программа может создать новые группы подпроцессов и подпроцессы, входящие в эти группы. Вначале создается группа — экземпляр класса ThreadGroup, конструктором
ThreadGroup(String name)
При этом группа получает имя, заданное аргументом name. Затем этот экземпляр указывается при создании подпроцессов в конструкторах класса Thread. Все подпроцессы попадут в группу с именем, заданным при создании группы.
Группы подпроцессов могут образовать иерархию. Одна группа порождается от другой конструктором
ThreadGroup(ThreadGroup parent, String name)
Группы подпроцессов используются главным образом для задания приоритетов подпроцессам внутри группы. Изменение приоритетов внутри группы не будет влиять на приоритеты подпроцессов вне иерархии этой группы. Каждая группа имеет максимальный приоритет, устанавливаемый методом setMaxPriorityfint maxPri) класса ThreadGroup. Ни один подпроцесс из этой группы не может превысить значения maxPri, но приоритеты подпроцессов, заданные до установки maxPri, не меняются.
Заключение
Технология Java по своей сути — многозадачная технология, основанная на threads. Это одна из причин, по которым технология Java так и не может разумным образом реализоваться в MS-DOS и Windows 3.1, несмотря на многие попытки.
Поэтому, конструируя программу для Java, следует все время помнить, что она будет выполняться в многозадачной среде. Надо ясно представлять себе, что будет, если программа начнет выполняться одновременно несколькими подпроцессами, выделять критические участки и синхронизировать их.
С другой стороны, если программа осуществляет несколько действий, следует подумать, не сделать ли их выполнение одновременным, создав дополнительные подпроцессы и распределив их приоритеты.
