Философия Java3

public static void main(String[] args) throws Exception { List

new ArrayList shapes = new ArrayList(); // Создание фигур, for(int i = 0; i < 10; i++)

shapes add(Shape.randomFactory()); // Назначение всех статических цветов: for(int i = 0; i < 10. i++)

((Shape)shapes.get(i)).setColor(Shape.GREEN); // Сохранение вектора состояния: ObjectOutputStream out = new ObjectOutputStream( new FileOutputStreamC'CADState.out")); out.writeObject(shapeTypes); Line.serializeStaticState(out); out.writeObject(shapes); // Вывод фигур: System out.printin(shapes);

}

} /* Output:

[class Circlecolor[3] xPos[58] yPos[55] dim[93] class Squarecolor[3] xPos[61] yPos[61] dim[29] продолжение &

. class Linecolor[3] xPos[68] yPos[0] dim[22]

. class Circlecolor[3] xPos[7] yPos[88] dim[28]

. class Squarecolor[3] xPos[51] yPos[89] dim[9]

. class Linecolor[3] xPos[78] yPos[98] dim[61]

. class Circlecolor[3] xPos[20] yPos[58] dim[16]

, class Squarecolor[3] xPos[40] yPos[ll] dim[22]

. class Linecolor[3] xPos[4] yPos[83] dim[6]

, class Circlecolor[3] xPos[75] yPos[10] dim[42] ]

*/// ~

Класс Shape реализует интерфейс Serializable, поэтому все унаследованные от него классы по определению поддерживают сериализацию и восстановление. В каждой фигуре Shape содержатся некоторые данные, и в каждом унаследованном от Shape классе имеется статическое (static) поле, которое определяет цвет фигуры. (Если бы мы поместили статическое поле в базовый класс, то получили бы одно поле для всех фигур, поскольку статические поля в производных классах не копируются.) Для задания цвета некоторого типа фигур можно переопределить методы базового класса (статические методы не используют динамическое связывание). Метод randomFactory() создает при каждом вызове новую фигуру, используя для этого случайные значения Shape.

Классы Circle и Square — простые подклассы Shape, различающиеся только способом инициализации поля color: окружность (Circle) задает значение этого поля в месте определения, а прямоугольник (Square) инициализирует его в конструкторе. Класс Line мы обсудим чуть позже.

В методе main() один список ArrayList используется для хранения объектов Class, а другой — для хранения фигур.

Восстановление объектов выполняется вполне тривиально:

// io/RecoverCADState java

// Восстановление состояния вымышленной системы CAD // {RunFirst StoreCADState} import java io.*. import java util *.

public class RecoverCADState {

@SuppressWarni ngs("unchecked")

public static void main(Stnng[] args) throws Exception { ObjectlnputStream in = new ObjectInputStream( new Fi1eInputStream("CADState.out")). // Данные читаются в том порядке, в котором они были записаны-List> shapeTypes =

(List shapes = (List)in.readObject(). System out println(shapes).

}

} /* Output

[class Circlecolor[l] xPos[58] yPos[55] dim[93] . class Squarecolor[0] xPos[61] yPos[61] dim[29] . class Linecolor[3] xPos[68] yPos[0] dim[22] . class Circlecolor[l] xPos[7] yPos[88] dim[28] . class Squarecolor[0] xPos[51] yPos[89] dim[9] . class Linecolor[3] xPos[78] yPos[98] dim[61]

. class

, class

, class

, class

]

*/// ~

Мы видим, что значения переменных xPos, у Pos и dim сохранились и были успешно восстановлены, однако при восстановлении статической информации произошло что-то странное. При записи все статические поля color имели значение 3, но восстановление дало другие результаты. В окружностях значением стала единица (то есть константа RED), а в прямоугольниках поля color вообще равны нулю (помните, в этих объектах инициализация проходит в конструкторе). Похоже, статические поля вообще не сериализовались! Да, это именно так — хотя класс Class и реализует интерфейс Serializable, происходит это не так, как нам хотелось бы. Отсюда, если вам понадобится сохранить статические значения, делайте это самостоятельно.

Именно для этой цели предназначены методы serializeStaticState() и dese-rializeStaticState() класса Line. Вы можете видеть, как они вызываются в процессе сохранения и восстановления системы. (Заметьте, порядок действий при сохранении информации должен соблюдаться и при ее десериализации.) Поэтому для правильного выполнения этих программ необходимо сделать следующее:

1. Добавьте методы serializeStaticState() и deserializeStaticState() во все фигуры Shape.

2. Уберите из программы список shapeTypes и весь связанный с ним код.

3. При сериализации и восстановлении вызывайте новые методы для сохранения статической информации.

Также стоит позаботиться о безопасности, ведь сериализация сохраняет и закрытые (private) поля. Если в вашем объекте имеется конфиденциальная информация, ее необходимо пометить как transient. Но в таком случае придется подумать о безопасном способе хранения такой информации, ведь при восстановлении объекта необходимо восстанавливать все его данные.

Предпочтения

В пакете JDK 1.4 появился программный интерфейс API для работы с предпочтениями (preferences). Предпочтения гораздо более тесно связаны с долговременным хранением, чем механизм сериализации объектов, поскольку они позволяют автоматически сохранять и восстанавливать вашу информацию. Однако они применимы лишь к небольшим, ограниченным наборам данных — хранить в них можно только примитивы и строки, и длина строки не должна превышать 8 Кбайт (не так уж мало, но вряд ли подойдет для решения серьезных задач). Как и предполагает название нового API, предпочтения предназначены для хранения и получения информации о предпочтениях пользователя и конфигурации программы.

Circlecolor[l] xPos[20] yPos[58] dim[16] Squarecolor[0] xPos[40] yPos[ll] dim[22] Linecolor[3] xPos[4] yPos[83] dim[6] Circlecolor[l] xPos[75] yPos[10] dim[42]

Предпочтения представляют собой наборы пар «ключ-значение» (как в картах), образующих иерархию узлов. Хотя иерархия узлов и годится для построения сложных структур, чаще всего создают один узел, имя которого совпадает с именем класса, и хранят информацию в нем. Простой пример:

//• io/PreferencesDemo.java

import java util prefs *;

import static net mindview.util Print *,

public class PreferencesDemo {

public static void main(String[] args) throws Exception { Preferences prefs = Preferences

.userNodeForPackage(PreferencesDemo class). prefs.put("Location", "Oz"); prefs put("Footwear", "Ruby Slippers"), prefs.putlntC"Companions". 4); prefs.putBooleanC'Are there witches?", true), int usageCount = prefs.getlntC'UsageCount". 0), usageCount++;

prefs putlntC"UsageCount". usageCount).

for(String key : prefs.keys())

print(key + ": "+ prefs.get(key. null));

// Всегда необходимо указывать значение по умолчанию:

print("How many companions does Dorothy have? " +

prefs.getInt("Companions". 0));

}

} /* Output: Location: Oz Footwear. Ruby Slippers Companions: 4 Are there witches?: true UsageCount- 53

How many companions does Dorothy have? 4 *///-

Здесь используется метод userNodeForPackage(), но с тем же успехом можно было бы заменить его методом systemNodeForPackage(), это дело вкуса. Предполагается, что префикс user используется для хранения индивидуальных предпочтений пользователя, a system — для хранения информации общего плана о настройках установки. Так как метод main() статический, для идентификации узла применен класс PreferencesDemo.class, хотя в нестатических методах обычно вызывается метод getClass(). Использовать текущий класс для идентификации узла не обязательно, но чаще всего именно так и поступают.

Созданный узел используется для хранения или считывания информации. В данном примере в узел помещаются различные данные, после вызывается метод keys(). Последний возвращает массив строк String[], что может быть непривычно, если вы привыкли использовать метод keys() в коллекциях. Обратите внимание на второй аргумент метода get(). Это значение по умолчанию, которое будет возвращено, если для данного ключа не будет найдено значение. При переборе множества ключей мы знаем, что каждому из них сопоставлено значение, поэтому передача null по умолчанию безопасна, но обычно используется именованный ключ:

prefs.getInt("Companions ". 0)),

В таких ситуациях стоит обзавестись имеющим смысл значением по умолчанию. В качестве характерного средства выражения часто выступает следующего рода конструкция:

int usageCount = prefs.getlntC"UsageCount", 0);

usageCount++;

prefs.putlnt("UsageCount". usageCount);

В этом случае при первом запуске программы значение переменной usage-Count будет нулем, а при последующих запусках оно должно измениться.

Запустив программу PreferencesDemo.java, вы увидите, что значение usage-Count действительно увеличивается при каждом запуске программы, но где же хранятся данные? Никакие локальные файлы после запуска программы не создаются. Система предпочтений привлекает для хранения данных системные ресурсы, а конкретная реализация зависит от операционной системы. Например, в Windows используется реестр (поскольку он и так представляет собой иерархию узлов с набором пар «ключ-значение»). С точки зрения программиста, реализация — это несущественно: информация сохраняется «сама собой», и вам не приходится беспокоиться о том, как это работает на различных системах.

Программный интерфейс предпочтений обладает гораздо большим возможностями, чем было показано в этом разделе. За более подробным описанием обратитесь к документации JDK, этот вопрос там описан достаточно подробно.

Резюме

Библиотека ввода/вывода Java удовлетворяет всем основным потребностям: она позволяет выполнять операции чтения и записи с консолью, файлами, буфером в памяти и даже сетевыми подключениями к Интернету. Наследование позволяет создавать новые типы объектов для ввода и вывода данных. Вы даже можете обеспечить расширяемость для объектов потока, использовав тот факт, что переопределенный метод toStringO автоматически вызывается при передаче объекта методу, ожидающему String (ограниченное «автоматическое преобразование типов» Java).

Впрочем, ответы на некоторые вопросы не удается найти ни в документации, ни в архитектуре библиотеки ввода/вывода Java. Например, было бы замечательно, если бы при попытке перезаписи файла возбуждалось исключение — многие программные системы позволяют указать, что файл может быть открыт для вывода только тогда, когда файла с тем же именем еще не существует. В языке Java проверка существования файла возможна лишь с помощью объекта File, поскольку если вы откроете файл как FileOutputStream или FileWriter, старый файл всегда будет стерт.

При знакомстве с библиотекой ввода/вывода возникают смешанные чувства; с одной стороны, она берёт на себя значительный объем работы и к тому же обеспечивает переносимость. Но пока вы не вполне поняли суть работы шаблона декоратора, архитектура библиотеки кажется не совсем понятной, и от вас потребуются определенные усилия для ее изучения и освоения. Кроме того, библиотека не совсем полна: например, только отсутствие необходимых средств заставило меня писать инструменты, подобные TextFile (новый класс Java SE5 PrintWriter — шаг в правильном направлении, но это лишь частичное решение). К числу значительных усовершенствований Java SE5 следует отнести и то, что в нем появились возможности форматирования вывода, присутствующие практически в любом другом языке.

Впрочем, как только вы действительно проникаетесь идеей шаблона декоратора и начинаете использовать библиотеку в ситуациях, где требуется вся ее гибкость, вы извлекаете из библиотеки все большую выгоду, и даже требующийся для надстроек дополнительный код не мешает этому.

Параллельное выполнение

До настоящего момента мы имели дело исключительно с последовательным программированием. Все действия, выполняемые программой, выполнялись друг за другом, то есть последовательно.

Последовательное программирование способно решить многие задачи. Однако для некоторых зайач бывает удобно (и даже необходимо) организовать параллельное выполнение нескольких частей программы, чтобы создать у пользователя впечатление одновременного выполнения этих частей, или — если на компьютере установлено несколько процессоров — чтобы они действительно выполнялись одновременно.

Каждая из этих самостоятельных подзадач называется потоком (thread)¹. Программа пишется так, словно каждый поток запускается сам по себе и использует процессор в монопольном режиме. На самом деле существует некоторый системный механизм, который обеспечивает совместное использованием процессора, но в основном думать об этом вам не придется.

Модель потоков (и ее поддержка в языке Java) является программным механизмом, упрощающим одновременное выполнение нескольких операций в одной и той же программе. Процессор периодически вмешивается в происходящие события, выделяя каждому потоку некоторой отрезок времени. Для каждого потока все выглядит так, словно процессор используется в монопольном режиме, но на самом деле время процессора разделяется между всеми существующими в программе потоками (исключение составляет ситуация, когда программа действительно выполняется на многопроцессорном компьютере). Однако при использовании потоков вам не нужно задумываться об этих тонкостях — код не зависит от того, на скольких процессорах вам придется работать. Таким образом, потоки предоставляют механизм масштабирования производительности — если программа работает слишком медленно, вы в силах легко ускорить ее, установив на компьютер дополнительные процессоры. Многозадачность и многопоточность являются, похоже, наиболее вескими причинами использования многопроцессорных систем.

Задачи

Программный поток представляет некоторую задачу или операцию, поэтому нам понадобятся средства для описания этой задачи. Их предоставляет интерфейс Runnable. Чтобы определить задачу, реализуйте Runnable и напишите метод run(), содержащий код выполнения нужных действий.

Например, задача LiftOff выводит обратный отсчет перед стартом:

//• concurrency/LiftOff java

// Реализация интерфейса Runnable

public class LiftOff implements Runnable {

protected int countDown =10; // Значение по умолчанию

private static int taskCount = 0,

private final int id = taskCount++;

public LiftOffО {}

public LiftOff(int countDown) {

this countDown = countDown;

}

public String status О {

return "#" + id + "(" +

(countDown > 0 ? countDown : "Liftoff!") + "), ";

}

public void run() {

while(countDown-- > 0) {

System.out.pri nt(status()); Thread.yieldO;

}

}

} ///:-

По идентификатору id различаются экземпляры задачи. Поле объявлено с ключевым словом final, поскольку оно не будет изменяться после инициализации.

Метод run() обычно содержит некоторый цикл, который продолжает выполняться до тех пор, пока не будет достигнуто некоторое завершающее условие. Следовательно, вы должны задать условие выхода из цикла (например, просто вернуть управление командой return). Часто run() выполняется в виде бесконечного цикла, а это означает, что при отсутствии завершающего условия выполнение будет продолжаться бесконечно (позднее в этой главе вы узнаете, как организовать безопасное завершение задач).

Вызов статического метода Thread.yield() в run() обращен к планировщику потоков (часть потокового механизма Java, обеспечивающая переключение процессора между потоками). Фактически он означает, что очередная важная часть цикла была выполнена и теперь можно на время переключиться на другую задачу. Вызов yield() не обязателен, но в данном примере он обеспечивает более интересные результаты: вы с большей вероятностью увидите, что программный поток прерывает и возобновляет свою работу.

В следующем примере метод run() не выделяется в отдельный программный поток, а просто вызывается напрямую в main() (впрочем, поток все же используется — тот, который всегда создается для main()):

//: concurrency/MainThread.java

public class MainThread {

public static void main(String[] args) { Liftoff launch = new LiftOffO; launch.run();

}

} /* Output-

#0(9). #0(8). #0(7), #0(6). #0(5). #0(4). #0(3). #0(2). #0(1). #0(Liftoff!).

*///:-

Класс, реализующий Runnable, должен содержать метод run(), но ничего особенного в этом методе нет — он не обладает никакими особыми потоковыми возможностями. Чтобы использовать многопоточное выполнение, необходимо явно связать задачу с потоком.

Класс Thread

Традиционный способ преобразования объекта Runnable в задачу заключается в передаче его конструктору Thread. Следующий пример показывает, как организовать выполнение LiftOff с использованием Thread:

//: concurrency/BasicThreads.java

// Простейший вариант использования класса Thread.

public class BasicThreads { public static void main(String[] args) { Thread t = new Thread (new LiftOffO); t.startO;

System.out.println("Waiting for LiftOff");

}

} /* Output: (90* match)

Waiting for LiftOff

#0(9). #0(8). #0(7). #0(6). #0(5). #0(4). #0(3). #0(2). #0(1). #0(Liftoff!).

*///:-

Конструктору Thread передается только объект Runnable. Метод start() выполняет необходимую инициализацию потока, после чего вызов метода run() интерфейса Runnable запускает задачу на выполнение в новом потоке.

Из выходных данных видно, что вызов start() быстро возвращает управление (сообщение «Waiting for LiftOff» появляется до завершения отсчета). В сущности, мы вызываем LiftOff.runQ, а этот метод еще не завершил свое выполнение;

но, поскольку LiftOff.run() выполняется в другом потоке, в потоке main() в это время можно выполнять другие операции. (Данная возможность не ограничивается потоком main() — любой поток может запустить другой поток.) Получается, что программа выполняет два метода сразу — main() и LiftOff. run().

В программе можно легко породить дополнительные потоки для выполнения дополнительных задач:

// concurrency/MoreBasicThreads java

// Добавление новых потоков

public class MoreBasicThreads {

public static void main(String[] args) { for(int i = 0, l < 5, i++)

new Thread(new LiftOffO) startO. System.out println("Waiting for LiftOff"),

#2(7), #3(7) #4(5), #0(4) #1(2), #2(2) #l(Liftoff!) *///:-#4(7), #0(6) #1(4), #2(4) #3(2), #4(2) #2(Liftoff!) #4(9), #0(8) #1(6), #2(6) #3(4), #4(4) #0(1), #1(1) #3(Liftoff!) #1(8), #2(8) #3(6), #4(6) #0(3), #1(3) #2(1), #3(1) #4(Liftoff!)

#3(8), #4(8). #0(7). #1(7).

#0(5), #1(5). #2(5). #3(5),

#2(3), #3(3). #4(3). #0(2).

#4(1), #0(Liftoff!),