Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

Здесь я постараюсь расписать серверную часть работы с сетью через Netty, может быть это кому-то будет полезно.

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

Миграционные скрипты

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

1. Рестарт сервера — самый простой и, обычно, самый не приемлемый способ;
2. Очистка кеша через определенные механизмы — пожалуй самый оптимальный по простоте и надежности метод. Этот метод можно вынести, например в JMX, на веб страничку или другой интерфейс и вызывать при необходимости. Гибкость метода в том, что пишется это один раз, а используется сколько угодно и где угодно. В случае, если Ваш провайдер кеша — EHCache и класс провайдер — SingletonEhCacheProvider, то Ваш код может выглядеть так:
   

   public String dumpKeys() {
       String regions[] = CacheManager.getInstance().getCacheNames();
       StringBuilder allkeys = new StringBuilder();
       String newLine = System.getProperty("line.separator");
       for (String region : regions) {
           Ehcache cache = CacheManager.getInstance().getEhcache(region);
           allkeys.append(toSomeReadableString(cache.getKeys()));
           allkeys.append(newLine);
       }
       return allkeys.toString();
   }
   

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

Нашел как-то на stack overflow вопрос (link).
Need to create java CLI programm that searchs for specific files matched some pattern. Need to use multi-threading approach without using util.concurrent package and to provide good performance on parallel controllers.
Перевод
Нужно написать консольную программу, которая ищет файлы по какому-то паттерну. Программа должна быть многопоточная, но нельзя использовать пакет util.concurrent. Требуется добиться максимальной производительности.


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

Введение

Так получилось, что как дизайнеру, мне необходим простор для творчества при реализации любых зачач в написании программ. Давно я положил глаз на такую платформу как Java, так-как всегда мечтал о кроссплатформенном программном обеспечении. И вот недавно, я решил освоить такой прекрассный компонент в Java, как JTable, ну и по той причине, что всегда любил использовать таблицы в своих программах.

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

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

За последнее время появилось несколько статей, рассказывающих о протоколе SOAP, а также описывающих процесс создания сервера на различных языках и платформах. Продолжим тему. В этой статье будет описываться создание сервера на языке Java с использование Apache CXF и Spring Framework. Предполагается, что читатель уже имеет общее представление об упомянутом протоколе, а также о работе с ant и maven. Для того, чтобы сделать задачу немного интереснее, добавим начальное условие: дана WSDL-схема, описывающая веб-сервис. Итак…
(Картинка из статьи на Wikipedia.)

Некоторое время назад я решал задачу автоматической покупки домена. Нужно было оформить в виде библиотеки (jar и файл настроек), которая использовалась бы в корпоративном приложении на Java. Я начал поиски DNS провайдеров с public API. Желательно, чтобы API были попроще, и домены подешевле — такой баланс оказалось не просто найти.

В предыдущей статье много комментаторов были не согласны в необходимости наличия знаний о размере объектов в java. Я категорически не согласен с этим мнением и поэтому подготовил несколько практических приемов, которые потенциально могут пригодится для оптимизации в Вашем приложении. Хочу сразу отметить, что не все из данных приемов могут применяться сразу во время разработки. Для придания большего драматизма, все расчеты и цифры будут приводится для 64-х разрядной HotSpot JVM.

Денормализация модели

Итак, давайте рассмотрим следующий код:

class Cursor {
    String icon;
    Position pos;
    Cursor(String icon, int x, int y) {
         this.icon = icon;
         this.pos = new Position(x, y);
    }
}
class Position {
    int x;
    int y;
    Position(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

А теперь проведем денормализацию:

class Cursor2 {
    String icon;
    int x;
    int y;
    Cursor2(String icon, int x, int y) {
        this.icon = icon;
        this.x = x;
        this.y = y;
    }
}

Казалось бы — избавились от композиции и все. Но нет. Объект класса Cursor2 потребляет приблизительно на 30% меньше памяти чем объект класса Cursor (по сути Cursor + Position). Такое вот не очевидное следствие декомпозиции. За счет ссылки и заголовка лишнего объекта. Возможно это кажется не важным и смешным, но только до тех пор, пока объектов у Вас мало, а когда счет идет на миллионы ситуация кардинально меняется. Это не призыв к созданию огромных классов по 100 полей. Ни в коем случаем. Это может пригодится исключительно в случае, когда Вы вплотную подошли к верхней границе Вашей оперативной памяти и в памяти у Вас много однотипных объектов.

У нас и rich client, и сервер активно используют Spring. И очень быстро возникла проблема — как использовать спринг бины из обычных классов (которые сами — не бины).

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

Вскоре я нагуглил в интернетах такой красивый вариант:

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

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

Очень часто вес приложения, которое мы выкладываем на сервер достигает неприлично больших размеров из-за включения в него всех нужных зависимостей. У меня в конечном итоге приложения занимают от 20 до 50 метров. Деплой таких war-ов на удаленный сервер, на Tomcat, дело не одной минуты, а при плохой связи и вовсе становится проблематичным. Класть библиотеки в ${tomcat.home}/lib дело очень неблагодарное и зачастую опасное. Мы на фирме немного погуглили и нашли очень приятное решение на DZone. Хочу с вами поделиться…

Java характеризуется динамической загрузкой классов. Для поиска и загрузки используется механизм делегирующих classloader'ов. В Java SE окружении их количество ограничивается 2-3, но в серверах приложений оно приближается к 10 иерархическим classloader'ам. Этим объясняется большое время запуска (обычно от минуты) и деплоя приложений.

В JBoss AS 7 разработчикам удалось сильно сократить время запуска (пустой appserver запускается за 3-4 секунды на рабочей станции). Этому способствовала новая система загрузки классов в данном сервере приложений. Такой подход всё же обладает своими недостатками.

Данная статья касается механизма загрузки классов в различных окружениях, особенностях работы с JBoss AS 7, сопряжения с системой сборки Apache Maven и IDE IntelliJ IDEA.

Не так давно, мне выпала задача, написать кеш, который сам себя чистит по истечению некоторого определенного времени. Требования к нему были следующие:

1. Легковесность
2. Потокобезобасность

В общем-то и все. До написания данной задачи с java.util.concurrent дела не имел. На мысль использования этого пакета меня натолкнул один мой коллега, у которого было нечто подобное, но не соответствовало тому функционалу который был нужен. Итак, начнем:

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

  В последнее время очень часто появляются фреймворки которые позволяют разработчику реализовывать функционал в свободном виде не прибегая к наследованию от интерфейсов. Примеры можно увидеть в таких как EJB 3, JUnit 4, JSF 2, Spring Framework 3 и т.д.
Под катом найдете обсуждение обоих подходов.

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

Эта статья — перевод первого туториала для проекта libGDX. Оригинал находится — здесь

От переводчика: недавно у меня появилось желание написать игру под Android. У меня есть некоторый опыт программирования на Java, но я почти не сталкивался с разработкой под Android. Тут я наткнулся на библиотеку libGDX, которая позволяет писать кросплатформенные игры. Также я наткнулся, что по ней не хватает русской документации, а конкретно — туториалов. Поэтому у меня появилось желание перевести туториалы. Это мой первый перевод, поэтому буду рад любым замечаниям и указаниям на неточности.

Настройка проекта

Примечание: есть проблемы с использованием Java 1.7 для Android-приложений. Убедитесь, что вы используете Java 1.6
Примечание: надо сделать несколько шагов для настройки приложения под Android. Смотрите ниже.

Эта статья описывает, как настроить Eclipse для разработки и запуска приложений как на настольном компьютере, так и на Android-устройствах.

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

Статья будет полезна всем, кому интересно узнать способ устранения ошибки LazyInitializationException при JAXB сериализации объектов, созданных при помощи Hibernate.
В конце статьи имеется ссылка на исходный код проекта, реализующего предложенное решение — использование custom AccessorFactory.

Для сравнения рассмотрено, как аналогичная проблема решена в популярном JSON-сериализаторе — Jackson.

Для начала немного уточним о чем идет речь. Wicket хранит последнюю просмотренную страницу в сессии, но в случае если страница очень большая, иногда это может стать проблемой. Для того что бы избежать этих проблем, можно попытаться сделать страницу Stateless(т.е. не имеющую состояния).
Итак, Stateless page — это страница не имеющая состояния, Statefull page — это страница с состоянием.

Stateless страницы не хранят никакого состояния из-за чего нет необходимости сохранять их от запроса к запросу.
Такие страницы не сохраняются ни в сессии ни в истории посещённых страниц хранящейся на диске, таким страницам не присваивается версия, как это происходит со statefull страницами. При каждом запросе к такой странице, её экземпляр создаётся заново.

На данный момент для платформы Android существует несколько решений, позволяющих реализовать ORM-подход для работы с базой данных, но основных два. Это ORMLite и GreenDAO.

Для новичков стоит сделать отступление и рассказать что такое ORM вообще. ORM — object-ralational mapping. Объектно-реляционное отображение означает, что программисту гораздо удобнее оперировать с объектами, которые он использует в своём приложении, нежели чем с таблицами, в которых хранятся данные в реляционных базах данных. Для связи реляционных СУБД с объектной моделью приложения используются ORM-технологии. Так для решения задач объектно-реляционного отображения в Android используют один из сторонних фреймворков. GreenDAO и ORMLite — являются библиотеками с открытым кодом.