В середине 2013 с выходом Java 8, язык начал поддерживать lambda-выражения, с тех пор минуло 4 года, было выпущено множество update-ов, грядет уже и выход Java 9 (которую, вероятно, мы сможем увидеть в этом году, не смотря на постоянные переносы сроков), таким образом на стыке времён, хотелось бы подвести итоги и оценить производительность нового в java и старого, как мир инструмента, дав ему количественную оценку.

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

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

К чему это приводит, можно глянуть здесь:

→ Отчет об активности сотрудников в социальных сетях в рабочее время (отчет)

С началом работы над Java 9 было анонсировано удаление критически важных классов из пакетов sun.* (понятное дело Sun, а в последствии и Oracle заявляли, что их использование является собственным риском компаний и проектов), что вызвало шквал критики и недовольства со стороны сообщества (ибо highload решения для которых производительность это все, используют скрытые возможности sun.*). Предыстория началась 15 лет назад с выходом версии языка 1.4, за это время большое количество библиотек, фреймворков, приложений успели внедрить закрытый код в свой.



Вот только не полный перечень проектов, которые у всех на слуху: Scala, Kafka, Akka, Hadoop, Cassandra, Hazlecast и прочие…

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

Корни вопроса начали расти из предыдущего проекта socmetr.ru, где понадобилось собирать большой объем информации из социальных сетей, и таким образом забивая единственный канал с интернетом. Анализ показал, что даже при наличии сжатия, объем поступающей информации так велик, что происходит его блокировка, при этом мощности CPU и Memory не задействованы и на 20%, а дисковая подсистема почти все время простаивает, то есть мы упёрлись в ширину канала, которую нам предоставляет провайдер.

Первая мысль была пойти экстенсивным путём и просто увеличить его возможности, немного остыв и призадумавшись, поняли, что перекладываем проблему на будущее. Само собой, возник вопрос: "Каким путём пойдем товарищи?". В результате реализовали следующую идею: