Java за рамками учебника

JDK: подноготная стандартной библиотеки. Часть 3. Java Core: строки

2008-06-30T13:14:39Z

Java задумывалась как язык, в котором на уровне синтаксиса и стандартной библиотеки обеспечивается более высокая безопасность в сравнении с обычными компиляторами вроде С и одновременно с этим более высокая производительность в сравнении с обычными интерпретаторами.

Именно с такими мыслями создавался объект String. Строка в Java является немодифицируемой. Как и для оберток, это сделано с целью обеспечить потоковую безопасность. Ведь если объект константен, то он thread-safe(en). Итак, вопрос с поточной безопасностью решен. А что же с производительностью?

Часто возникает необходимость конкатенировать большое количество строк. Если делать это с помощью одних только строк, то возникает существенное падение производительности:

static String readStream(Reader is) throws IOException {
  BufferedReader isr = new BufferedReader(is);
  String result="";
  String buffer;
  while ( (buffer = isr.readLine()) !=null) {
    result+=buffer + "\n";
  }
  return result;
}

Задача на дом №1: Какие проблемы производительности у приведенного кода? Чему асимптотически равен суммарный объем всей выделенной памяти в этом методе?

Специально для таких случаев в JDK предусмотрены классы StringBuffer и StringBuilder. Оба класса представляют из себя строковой буфер для множества последовательных конкатенаций. В чем отличия этих классов? (хороший вопрос на собеседование). Отличие в том, что StringBuffer является thread-safe, а StringBuilder - нет.

Совет: используй StringBuilder там, где это возможно и StringBuffer - там, где это необходимо.

Поскольку предполагается использование StringBuffer в многопоточной среде, то данные в буфер скорее всего будут записываться в хаотичном порядке. Доказательство от противного: если порядок записи в StringBuffer четко определён, то это означает наличие дополнительной рукописной синхронизации, из чего следует, что доступ к StringBuffer синхронизирован, и в этом случае следует использовать StringBuilder. Я вижу только один тип задач, которые следует решать средствами StringBuffer - это задачи протоколирования событий в системе. Например, логирование. Предлагаю читателям попробовать опровергнуть это утверждение или привести еще примеры использования StringBuffer.

И так, если строковой буфер находится в локальном контексте потока, то используем StringBuilder, иначе - StringBuffer.

Правильная реализация предыдущей задачи с использованием StringBuilder:

static String readStream(Reader is) throws IOException {
  BufferedReader isr = new BufferedReader(is);
  StringBuilder result = new StringBuilder();
  String buffer;
  while ((buffer = isr.readLine()) != null) {
    result.append(buffer).append("\n");
  }
  return result.toString();
}

Задача на дом №2 (сложная): Чему асимптотически равен суммарный объем всей выделенной памяти в этой реализации?

А вот интересные результаты тестирования производительности этих классов

JDK: подноготная стандартной библиотеки. Часть 2. Java Core: обертки

2008-06-29T11:15:40Z

В java в отличие от например С потребовалось четко разделить понятия примитивных типов и объектов. Здесь объекты всегда хранятся по ссылке, а примитивы - всегда по значению.

Если мы хотим сказать, что данное поле конкретного примитивного типа, то используем примитив.

Если мы хотим сказать, что данное поле какого-то примитивного типа, то используем базовый тип всея объектов - Object.

Такой тип означает ссылку на всё, что угодно. Но ссылаться на примитив мы не можем, значит, используем ссылку на "объект, похожий на примитив" - обёртку. Поэтому были созданы классы обертки Byte, Double, Float, Integer, Long, Short, Character, целью которых является предоставление унифицированного доступа к примитивным типам.

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

примитивные типы атомарны, следовательно, они thread-safe(en). Самый экономичный способ достичь этого - сделать константный объектный аналог примитивного типа.
примитивные типы передаются всегда по значению. Следовательно нет возможности через параметр вернуть значение примитивного типа или случайно его модифицировать в методе. Простой способ добиться этого - опять же константная оболочка.

Пример:

static void increment(Integer i) {
i ++ ;
}

Здесь увеличенное значение i не возвращается вызвавшему методу. Имитируется передача параметра по значению.

Совет: используйте примитивы везде, где можете, а обертки - только там, где это необходимо.

Рассмотрим для примера решение задачи увеличения элементов массива на некоторую величину для векторов и массивов.
Используется синтаксис Java 2:

static void incArray(int []m, int v) {
  for (int i=0; i<m.length; i ) {
    m[i] += v;
  }
}

static void incList(List l, int v) {
  for (int i=0;i<l.size(); i ) {
    l.set(i, new Integer(((Integer)l.get(i)).intValue()+ v));
  }
}

Для массивов можно воспользоваться примитивными типами. Операция увеличения ячейки массива выполняется простым оператором. В случае со списком аналогичная операция включает в себя три вызова метода, оператор сложения, создание одного и удаление другого объекта (предыдущего значения элемента списка). Конечно, это приводит не только глаза в кучу, но и значительно снижает производительность приложения.

А как же синтаксис Java 5?

static void incListJava5(List<Integer> l, int v) {
  for (int i=0;i<l.size(); i ) {
    l.set(i, l.get(i) +v);
  }
}

Казалось бы, осталось всего два вызова метода и оператор сложения. Но это всего лишь syntax sugar - небольшое синтаксическое улучшение. Оно не должно вводить в заблуждение о количестве выполняемых кодом операций. В последнем примере остались все те же три вызова методов, сложение и создания, удаления объектов.

Красота достигается за счет нововведения java 5 - autoboxing. Autoboxing автоматически преобразует примитивные типы к их аналогам оболочкам и наоборот.

Будьте внимательны с autoboxing! Из-за неявных преобразований, могут возникнуть недопонимания. Следующий код не будет корректно решать задачу. В чем проблема этого кода предлагаю ответить моим читателям белым шрифтом в комментариях.

static void incListJava5(List<Integer> l, int v) {
  for (Integer i:l) {
    i +=v;
  }
}

Вроде бы всё ясно. Но кому тогда нужна оболочка java.lang.Void ?? Об этом - в следующих статьях.

JDK: подноготная стандартной библиотеки. Часть 1. Java Core: java.lang.Object

2008-06-29T11:13:39Z

JDK - как много в этом звуке для сердца джавера слилось!

Действительно ли так много? Да, 19184 класса в моей JDK 1.6.0 UPDATE 3. Большая часть из них закрыта, но и оставшихся нескольких тысяч открытых классов больше, чем достаточно. Но ведь даже сертифицированному Java программисту нелегко на память перечислить хотя бы полсотни из них!

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

С чего начнем? Конечно, с java core!

java.lang.*

Этот пакет представлен классами обертками, основными классами исключений, классами Object, Class, Math, System, Runtime, Thread, ThreadLocal, String, StringBuffer, StringBuilder.

Все данные в Java делятся на объекты и примитивные типы. Примитивные типы нам неинтересны - их знает даже программист на BASIC. А все объекты являются наследниками java.lang.Object. Если не знаешь, что такое наследование, то тебе скорее всего сюда.

java.lang.Object обладает тем поведением, которым должен обладать любой объект в Java. Что это за поведение?

public boolean equals(Object obj);

Метод выполняет проверку на эквивалентность другому объекту. Реализация по-умолчанию проверяет совпадение ссылок на объект - это работает очень быстро и обладает адекватной семантикой. Твоя реализация может:

Сравнивать уникальные идентификаторы объекта
Сравнивать "первичные ключи" - уникальные наборы полей
Выполнять полную (глубокую) проверку эквивалентности полей объекта

Дальше курсив - это возможная реплика абстрактного читателя.
- А зачем это вообще надо? Я вот никогда не использую этот метод. У себя в программе вообще могу написать отдельную функцию, сравнивающую объекты или определить свой метод myequals внутри объекта. Он будет так же хорош для моей задачи.
- equals активно используется контейнерами стандартной библиотеки. Не определил у себя в объекте нормальный equals - лишился возможности использовать объект в контейнере.

public int hashCode();

Метод создает хэш код объекта. По умолчанию хэш код генерируется из адреса объекта. Этот метод нужен только для использования внутри хэш таблиц (java.util.HashSet) . Зачем ради каких то хэш таблиц заводить целый метод для всех(!) объектов языка? Затем, что хэш таблицы и карты используются в языке повсеместно. А если ты еще не используешь их, то мы идём за тобой!

Правило: Если твои объекты совпадают по equals, то у них обязан быть одинаковый hashCode. Если объекты различаются по equals, то рекомендуется сделать для них разный hashCode. Подробнее расскажу в теме о контейнерах.

Правило: всегда переопределяйте equals одновременно с hashCode, если собираетесь использовать объект вместе с хэш таблицами!

protected void finalize()

Очень странный метод, который по стандарту может вызваться при разрушении объекта. А может и не вызываться. Раз он такой непостоянный, то не стоит вообще на него обращать внимания. И даже не пытайтесь закрывать в нем открытые ранее потоки/файлы/сокеты! И не стоит путать его с деструкторами объекта из С++.

Совет: забей на finalize

public final Class getClass();

Метод получает класс объекта. Логично, что его нельзя переопределить, а тем, кому всё же хочется, следует руки поотрывать.

Совет: если вам понадобился getClass(), то, возможно, лучше модифицировать эту часть кода с использованием полиморфизма.

protected native Object clone() throws CloneNotSupportedException;

Метод возвращающий поверхностную копию(en) данного объекта. Используется как конструктор копирования в с++.
По-умолчанию является наследуемым (protected) и в случае, если объект не реализует интерфейс Coneable, кидает исключение CloneNotSupportedException. Вопрос того, почему clone() является protected, да еще и кидает исключения, донимает лучшие умы тысячелетия. Моё объяснение этого феномена таково: clone является protected по той причине, что разработчики jdk дают нам возможность использовать функционал поведения clone по-умолчанию, но при этом не хотят чтобы, опасная и неочевидная семантика поверхностного копирования была по-умолчанию доступна всем пользователям объекта.

У clone есть два серьезных недостатка:
1. clone возвращает Object. Это даёт повод возвращать объекты другого типа. Но за такие вещи нужно наказывать двухнедельными принудительными работами на языке Cobol.
2. Если ты знаешь, что некий наследник класса Object можно клонировать, то ты не вызовишь метод clone иначе, как через reflection api. Например, в твоей нетипизированной коллекции находятся различные объекты. Некоторые из них можно клонировать, т. е. они реализуют интерфейс Cloneable. К какому общему базовому интерфейсу нужно выполнить кастомизацию типа, чтобы вызвать метод clone? По-умолчанию нет такого интерфейса. Сам Cloneable не содержит внутри себя объявления открытого метода clone. Cloneable - пустой интерфейс и по сути является всего лишь меткой.

Более подробно про метод clone.

Совет: хотите заниматься клонированием? Заведите нормальный интерфейс Clone:

interface Clone<T> extends Cloneable {
  public T clone() throws CloneNotSupportedException;
}

static class Dolly implements Clone<Dolly> {
  private String DNA;

  public Dolly(String s) {
    DNA = s;
  }

  public Dolly clone() throws CloneNotSupportedException {
    return (Dolly) super.clone();
  }
}

public static void main(String[] args) throws IOException, CloneNotSupportedException {
  Dolly dolly = new Dolly("TTAGGCGGCATTACGG");
  ArrayList myObjects = new ArrayList();
  myObjects.add(new Integer(123));
  myObjects.add(dolly);
  Set clones = new HashSet();
  for (Object o : myObjects) {
    if (o instanceof Clone) {
      clones.add(((Clone) o).clone());
    }
  }
  // здесь в clones находится только один объект Dolly
}

Остались методы notify, notifyAll, wait, которые используются для организации многопоточности. О них я постараюсь написать в статье про потоки.

Также есть метод toString, не представляющий никакого интереса для любознательных кроме того, что позволяет выполнять приведение типа к String автоматически:

System.out.println("Dolly's value is "+new Dolly());

Все эти методы пришли к нам из далекого прошлого становления языка Java. Не судите их слишком строго.

Примерный список тем для статей

2008-06-28T21:37:19Z

По вашим многочисленным просьбам выкладываю примерный список тем, которые собираюсь осветить в ближайшее время.

Паттерны/Антипаттерны.
Рефакторинг. Автоматический рефакторинг в Intellij Idea
Алгоритмическая оптимизация. Обзор основных алгоритмов. Динамическое программирование против тормозных задач.
Языковая оптимизация.
Хитрости стандартной библиотеки.
Библиотеки apache commons как расширения стандартной библиотеки.
Hibernate. Как его приручить?
Spring vs Struts.
DWR, GWT, другие Ajax фреймворки. Сравнение, рекомендации по выбору подходящего.
Java Generics vs C++ Templates.
Новшества Java 6

В этот список могут попасть темы, предложенные вами!

Темы моих читателей:

Velocity
Веб сервисы

Не изобретайте колёса! 6 причин пользоваться существующими

2008-06-28T14:27:58Z

- Ну хватит уже этих банальностей про колёса, надоело! - скажешь ты.

А вот и не хватит! В современном научном мире и мире программирования колёса изобретают только ~~идиоты~~бунтари и студенты - в качестве домашнего задания.

Java - это такой особенный язык, разработчики которого очень продуманно подошли к проблеме разработки стандартных библиотек. Так что колес здесь своих достаточно на любой вкус и цвет. ~~Глотай~~ бери - не хочу!
Вот список из 6 причин использовать существующие наработки для тех, кто еще не уверовал:

1. Свое колесо - восьмеркой.
Доказательство тривиальное. Чем больше написано кода, тем больше допущено ошибок. Значит, код вашего колеса вероятно будет содержать ошибки. С другой стороны штампованое серийно выпущенное колесо (многократно протестированные библиотеки) содержит минимум ошибок.

Возьмем классическую задачу сортировки массива. Пусть требуется отсортировать массив Person по неубыванию имени. Сортировка выполняется по имени или фамилии в зависимости от параметра.

class Person {
  String name;
  String surname;

  String getName(int index) {
    return index == 0 ? name : surname;
  }
}

void nativeSort(Person[] persons, final int index) {
  Arrays.sort(persons, new Comparator<Person>() {
    public int compare(Person o1, Person o2) {
      return o1.getName(index).compareTo(o2.getName(index));
    }
  });
}

void mySort(Person[] persons, int index) {
  for (int i = 0; i < persons.length - 1; i++) {
    for (int k = 0; k < persons.length - 1; k++) {
      if (persons[k + 1].getName(index).compareTo(persons[k].getName(index)) <= 0) {
        Person buf = persons[k];
        persons[k] = persons[k + 1];
        persons[k + 1] = buf;
      }
    }
  }
}

На первый взгляд, оба решения совершенно правильные. Одно из них использует библиотечную функцию сортировки, а второе реализует алгоритм сортировки пузырьком. Но оказывается, что своё решение обладает серьезным недостатком, который может повлечь неприятные последствия в реальном коде. Каким? Не скажу! Это задачка для самостоятельной работы :). Ответы просьба писать в комментариях белым шрифтом.

2. Свое колесо катится медленнее. В примере из первого пункта используется сортировка пузырьком. Как известно, она выполняется за квадратичное время. А стандартная сортировка использует алгоритм merge sort, обладающий сложностью N*log(N), что работает значительно быстрее. Этот пример не доказывает все случаи, но всё же, в большинстве случаев самописный код работает медленнее библиотечного.

3. Свой код дороже поддерживать. Код своих библиотек так или иначе придется поддерживать. Потребуется рефакторинг, доработка, отимизация, отладка с чашкой кофе в три ночи. А использование готовых библиотек позволяет - только задумайтесь - перебросить разработку части функционала на сторонних (часто более надежных) разработчиков.

4. Знание стандартных библиотек поможет тебе легче понимать чужой код. Ведь стандартные библиотеки на то и стандартны, что их используют разные команды.

5. Модули, использующие стандартные библиотеки и интерфейсы, проще интегрируются. Интеграция модулей включает обмен данными. Если данные не станадртизованы, то придется писать конвертеры. Например, вы хотите соединить в своём проекте библиотеку для работы с http соединениями org.apache.commons.httpclient.* и библиотеку для работы с xml javax.xml.parsers.*. Гарантирую головную боль, связанную с тем, что в этих библиотеках используется разный класс для описания URL (java.net.URL и org.apache.commons.httpclient.HttpURL)

6. Разработчики библиотек часто лучше тебя знают, в чем ты нуждаешься. Это похоже на теорию заговора? - Вовсе нет. Стандарты в мире java принимаются консорциумом(en), а, значит, принятые решения подходят большинству команд разработчиков. А раз они подходят почти всем, то наверняка, подойдут и тебе. Здесь можно вспомнить про другие(en) технологии, которые разрабатываются полностью внутри компаний, что может (но не обязательно) сделать их недостаточно удобными для тебя.

Жду от вас новых пунктов к этому списку или камней в мой огород. Приветствуется всё!

Оптимизируй с умом

2008-06-28T11:59:32Z

Допустим, я изучил новый язык программирования. Пусть это будет ... Java. Я уже прочитал книжку неизвестного автора "введение в Java", умею создавать приложение "hello world", и даже читать строчки из одного файла и записывать их в другой. Куда мне теперь стремиться как разработчику? Какие умения нужно развивать и какие характеристики программ улучшать? Для того, чтобы ответить на эти вопросы, нужно сформулировать критерии хорошей программы:

Хорошая читаемость кода
Безошибочность
Компактность кода
Высокая производительность
Невысокие требования к оперативной памяти
Небольшой объем исполнимого кода на диске

Кому-то (участникам олимпиад по программированию) интересна высокая производительность. Для кого-то (руководители софтверных проектов) важнее безошибочность и поддерживаемость кода. Есть и такие(разработчики для j2me), кто из кожи вон лезут, чтобы уменьшить расходы памяти. У каждого может быть свое мнение, но все должны знать об общепринятых приоритетах этих критериев.

Самым важным параметром программы в современном мире коммерческого программирования считается хорошая поддерживаемость(читаемость) кода. Если код можно поддерживать, то из глючной программы можно сделать безошибочную, из медленной - производительную, из вредительски пожирающей системные ресурсы - программу со скромными требованиями. Кроме того, распространенные схемой разработки ПО, такие как "спиральная модель(en)" накладывают на код требования хорошей поддерживаемости.

Следующим по важности критерием является безошибочность. Здесь, надеюсь, убеждать никого не придется :). Я уже слышу недовольные возгласы вдумчивого читателя: "А как часто безошибочен неподдерживаемый код?". Безошибочный неподдерживаемый код - это такой, который хорошо протестирован, но при этом ~~никогда~~ очень давно не рефакторился. Кратко: рефакторинг - это процесс повышения читаемости кода.

И на третье место можно поставить компактность и производительность. То, что эти критерии стоят на третьем месте, не должно умалять их значимости для заинтересованного в профессиональном росте разработчика. Обеспечив хорошую поддерживаемость и корректность кода, нужно позаботиться и о нервной системе пользователя. А пользователь, как известно, очень не любит ждать.
Замечено, что почти любая неалгоритмическая оптимизация приводит к снижению читаемости кода.

Рассмотрим для примера график:

График показывает зависимость производительности кода от читабельности. Здесь синие кружки означают различные стадии оптимизации кода. Разумная стратегия разработки выглядит так:
1. В процессе разработки придерживаемся максимальной поддерживаемости кода (левый кружок)
2. На конечной стадии разработки начинаем выполнять оптимизацию. При этом из всех возможных оптимизаций выбираем такую, которая гарантированно обеспечивает необходимую производительность(optimum) и при этом является максимально поддерживаемой. Это состояние выделено стрелочкой.

Этот блог будет в основном посвящен обзору приемов достижения перечисленных критериев качества кода. Ссылки на литературу и хорошие примеры кода гарантируются!

Тест: являешься ли ты моим читателем?

2008-06-27T22:44:54Z

Добрый день, дорогой читатель!

Это первая запись в моем блоге, посвященном разработке на платформе Java. Сначала я хочу пояснить, кому может быть интересен этот блог.

Мой читатель :
* разработчик ПО или соболезнующий разработчикам ПО
* владеет основами программирования на java или другом с-подобном языке.
* не думает, что ООП - это организация освобождения Палестины
* интересуется вещами, выходящими за рамки учебников
* любит оптимизировать и автоматизировать свои ежедневные задачи

Если для тебя хотя бы три из пяти пунктов совпали, то нам по пути! :)

Часто для того, чтобы объяснить, чем блог является, проще указать, чем он не является:
* Это НЕ форум о java, алгоритмах и прочем IT
* Это НЕ учебник по Java
* Это НЕ обзор Java технологий в чистом виде

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

До новых встреч!