Данная статья является частью серии статей о том, как пишутся low-latency торговые приложения. Вводная статья содержит начальные сведения о подходах к оптимизациям вообще, вторая статья рассказывает об подходах к оптимизации на всех уровнях торговой системы: от железа до настройки JVM. Данная же статья, рассказывает уже подробно об оптимизациях в самом Java-приложении.
Статья ориентирована на программистов, чтобы помочь им в изучении Java, понимании JVM и развитии навыков программирования.
В торговых приложениях создается множество объектов в реальном времени. Скажем, каждый новый ордер от клиента создает объект Order. Исполнение ордера на рынке порождает новый объект Fill или Partial Fill. И если поток ордеров очень высок во время активного торгового дня, это создание новых объектов оказывает:
Все эти операции имеют большие накладные расходы сами по себе, плюс могут привести к непредсказуемым задержкам, поэтому Java-программисты нашли обходное решение этой проблемы: использовать пулы заранее созданных объектов (object pools). Т.е. переиспользовать объекты, которые уже не нужны, вместо создания новых.
Чтобы было понятно, на чём следует концентрироваться при оптимизации, слайд из доклада «Создание программных систем в Google и его уроки»:
Читать далее
Отличное видео о настройке Linux для low-latency торговых систем.
Читать далее
Данная статья является частью более общей статьи об оптимизациях торговой системы на всех уровнях.
JVM предназначена для запуска широкого спектра Java-приложений. Для общего случая параметры, используемые JVM по умолчанию, вполне подойдут. Но если мы хотим добиться определенных результатов производительности, требуется тонкая настройка JVM с помощью определенных стартовых параметров.
Как видно из предыдущих статей JIT-компилятор на 4-ом уровне способен создавать высокопроизводительный нативный код. В некоторых случаях, благодаря сбору статистки в реальном рабочем окружении, нативный код получается даже лучше, чем код созданный статическим компилятором из исходников C/C++. Именно поэтому Java-программисты заявляют, что Java-приложение по скорости может превзойти приложение, написанное на C/C++.
Как же нам достичь этого уровня компиляции, если для его достижения требуется 15.000 исполнений?
JIT-компилятор — встроенный в JVM компилятор байткода в машинный код. Проведя множество интервью с кандидатами на роль Core Java Developer, я был удивлен тем, что многие кандидаты даже не подозревали о существовании такой технологии в JVM, а те, кто краем уха что-то слышал, не могли объяснить, как она работает. Может быть для написания J2EE или веб-приложений этих знаний и не требуется, но для работы в области low-latency trading эти знания — ключевые.
Описание JIT-компилятора хорошо дано в книгах:
В данной статье я просто изложу основы, без знания которых непонятны будут другие статьи по low-latency оптимизации JVM.
В предыдущей статье я говорил об оптимизации вообще, а теперь приведу несколько советов по low-latency оптимизациях в Java-приложениях на всех уровнях торговой системы:
Несколько мыслей об оптимизации вообще, оптимизации Java-приложений и оптимизации для достижения low-latency.
