Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Любовь и злоба к Java 8

Anna | 5.06.2014 | нет комментариев

Похоже Java 8 самый ожидаемый релиз всех времен. Первоначально планирующий релиз на сентябрь прошлого года, перенесли на март дальнейшего года, ориентировочно для того, что бы потратить огромнее времени надоработки безопасности, в основном направленные на клиентскую часть Java (JavaFX/Swing).

Новая версия Java пытается “совершенствоваться” так, как понимает это слово Microsoft. Это обозначает кражу огромный части пророческой, о которых заботились другие фреймворки и языки, после этого включение их в язык либо runtime. В преддверии нового релиза, сообщество Java обговаривает Project Lambda, stream, functional interfaces и другие плюшки. Так давайте разглядим что отлично, а что мы можем возненавидеть.

Stream

Основное новшество это коллекция, называемая Stream, не путайте с InputStream и OutputStream. Stream не замещает ArrayLists либо другие коллекции. Это новшество разрешает руководить данными стремительней и легче. Stream — это одноразовый объект, т.е. обработать данные в нем дозволено один раз.

Stream владеет вероятностью применить функции filter, map, reduce для его обработки. Для Stream есть два режима: ступенчатый и параллельный. Это разрешает задействовать вероятности многоядерных процессоров. Коллекции применяют fork/join параллелизм для разбиения работы на части.

Для последовательного режима:

List <Person> people = list.getStream.collect(Collectors.toList());

Для параллельного режима:

List <Person> people = list.getStream.parallel().collect(Collectors.toList());

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

Обработка в параллельном режиме выглядит так:

List originalList = someData;
split1 = originalList(0, mid);
split2 = originalList(mid,end);
new Runnable(split1.process());
new Runnable(split2.process());
List revisedList = split1   split2;

Stream может быть обработан только раз, и он возвращает иной Stream, следственно для приобретения пригодного итог дозволено применить окончательную (terminal) функцию. Скажем, функции sum(), collect(), toArray(). Пока к Stream не применена окончательная функция, итог обработки не вычисляется. Скажем:

Double result = list.getStream().mapToDouble(f -> f.getAmount()).sum();
List<Person> people = list.getStream().filter(f -> f.getAge() > 21).collect(Collectors.toList());

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

Functional Interfaces

В целом это легко добавление default-способов в интерфейс с вероятностью их прямого вызова из интерфейса. Так же их не непременно переопределять в реализации интерфейса.

Это было сделано для обратной совместимости с вашими коллекциями в ваших интерфейсах. Т.е. решение задачи помещения Stream в интерфейс без необходимости изменять все реализующие данный интерфейс классы. Следственно, создание default-способа в интерфейсе разрешает каждому реализующим интерфейс классам применять потоки. Если default-способ не правилен, то он может быть перегружен.

По существу default-способы это форма множественного наследования. И это становится загвоздкой того, кто реализует интерфейс, т.к. ему всё равно понадобится переопределить способ. Так же реализующий интерфейс может предпочесть, какой базовый способ (supermethod) применять, это обозначает что множество классов реализующий интерфейс могут измениться.

Об этой детали в Java 8 волнуется много людей. Ванная Node.jar. В чем уверено множество людей, так это в том, что они хотят запускать любые штуки на JVM, но не хотят применять для этого синтаксис Java.

Есть места, где пригоден запуск JavaScript из Java. Скажем, дозволено применять client-side validator, как server-side validator, т.е. иметь один и тот же код, работающий в 2-х местах. Иметь свой личный Node.js совместно с Java — это как обзавестись милым монстриком, кто не хочет такого? Если читая данный текст, вы не уверены, серьезен я либо нет, то это делает нас схожими.

Accumulators

Вначале был synchronized. Впрочем, если все что вам необходимо делать это увеличивать счетчик из многих потоков, то synchronized тяжеловат для этой задачи. Он стал не такой весомый в Java 6, сделав неисчислимые блокировки дешевле. В основном это помогло ветхим приложениям, все ещё использующим Vector, это однопоточный хлам, тот, что поразил всякую библиотеку в Java Activation Framework.

С возникновением пакета java.util.concurrent стало отменнее — пул потоков и другие трудные многопоточные конструкции, но если все, что вы хотите это легко увеличение счетчика потоками, это все было излишне. Для этого нам были даны atomic-и — стремительные и легче, чем реальные блокировки. Впрочем Doug Lea и его любимая армия студентов выпускников еще не завершила. В JDK 8 нам дадут accumulators и adders. Они больше легкие, чем atomic-и, и с ослабленными гарантиями, это то, что огромнее каждого необходимо параллельному коду, увеличивающему всеобщий счетчик. Жду увидеть это новшество в реализациях map/reduce. Впрочем вам все еще необходимы atomic-и, если вы хотите читать значение счетчика в потоках, так как порядок аккумулирования счетчика не гарантирован.

Исправления HashMap

Существует знаменитый баг, связанный с тем, как String.hashCode() реализован в Java. Если огромное число параметров имеют идентичный хеш, это вызовет Непомерную нагрузку на CPU при работе с HashMap. Такая обстановка может появиться, если приложение подвергнется denial-of-service атаке, как в этом случае.

Теперь, корзины в HashMap применяют связанный список для хранения значений. Если есть огромное число коллизий, тогда трудность работы со конструкцией изменяется от O(1) до O(N). Сейчас при достижении определенного числа элементов в корзине, корзина переключится на применение сбалансированного дерева, что снижает трудность до O(log n).

TLS SNI

SNI — это не имя персонажа Dr. Seuss, а Server Name Identification. Все любят SSL либо TLS, либо как это сейчас именуется. Много сайтов применяют один и тот же IP и name-based virtual host. Что обозначает, что вторая строка HTTP запроса это имя хоста. Я могу сделать запрос на podcastd.infoworld.com иwww.infoworld.com, находящиеся но одном и том же IP, но получить различные страницы, из-за различного имени хоста. Впрочем я не могу удерживать много сайтов на одном IP из-за SSL. Для всякого SSL сертификата я должен иметь обособленный IP адрес. А если припомнить грустную обстановку с текущим числом IP адресов в IPv4, то все становится еще печальнее.

Но сейчас Java поддерживает SNI. Множество современных браузеров поддерживает SNI, Apache поддерживает и Java сейчас тоже поддерживает. Это обозначает, то чего мы так длинно ждали — Tomcat и другие основанные на Java серверы, использующие неторопливую реализацию SSL от Oracle (JSSE), сейчас поддерживают SNI.

Завершение

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

От переводчика

Это перевод вот этой статьи 
Увидел в комментариях желание прогровчан узнать про плюшки Java 8, да и сам хотел, и здесь попалась эта статья, так что вот сел и перевел. Перевод не буквальный, но я постарался сделать какдозволено ближе к тексту, нежножко пришлось выбросить, т.к. автор статьи шутит, а его шутки переводить трудно. Следственно знатокам английского сурово рекомендую читать оригинал.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB