Данная статья является частью серии статей о том, как пишутся low-latency торговые приложения. Вводная статья содержит начальные сведения о подходах к оптимизациям вообще, вторая статья рассказывает об подходах к оптимизации на всех уровнях торговой системы: от железа до настройки JVM. Данная же статья, рассказывает уже подробно об оптимизациях в самом Java-приложении.
Статья ориентирована на программистов, чтобы помочь им в изучении Java, понимании JVM и развитии навыков программирования.
Краткий список сайтов, которые я стараюсь посещать ежедневно, чтобы быть в курсе последних новостей о Java и о том, что происходит в сфере биржевых технологий и финансового бизнеса.
В торговых приложениях создается множество объектов в реальном времени. Скажем, каждый новый ордер от клиента создает объект Order. Исполнение ордера на рынке порождает новый объект Fill или Partial Fill. И если поток ордеров очень высок во время активного торгового дня, это создание новых объектов оказывает:
Все эти операции имеют большие накладные расходы сами по себе, плюс могут привести к непредсказуемым задержкам, поэтому Java-программисты нашли обходное решение этой проблемы: использовать пулы заранее созданных объектов (object pools). Т.е. переиспользовать объекты, которые уже не нужны, вместо создания новых.
В финансовых расчетах часто приходится оперировать дробными числами. Например, на некоторых рынках цены на опционы и фьючерсы могут иметь два и даже три знака после запятой. Цены на некоторые акции могут выражаться в пенни, так называемые penny-stocks. Для валидации ордеров перед отправкой на рынок надо проверять, не выходит ли указанная цена ордера за определенные пределы (price limits), рассчитанные от текущей рыночной цены инструмента. Например, надо вычислить +/-5% от цены 1.005. Казалось бы для выражения цены в Java идеально подходит примитивный тип double. Но это крупная, опасная ошибка!
Отличная презентация The Ghosts of Java Past, Present and Yet to Come об истории Java и том, какие языки послужили источником вдохновения при ее создании: LISP, Simula, C, Modula, SmallTalk, Pascal (p-code), Mesa, Cedar, Objective-C, Ada, C++.
В настоящее время Oracle перевела выпуск Java на шестимесячный цикл. В результате каждые шесть месяцев мы имеем новую версию Java, а в каждый данный момент времени — сразу несколько «живых» версий, в которых можно запутаться. Изложу свои мысли на эту тему.
Хорошие люди собрались и сделали полезную страницу со ссылками на все известные дистрибутивы Java. Теперь любой разработчик легко может пройти по ссылкам и скачать любую JVM, чтобы пощупать, померять, сравнить.
Данная статья является частью более общей статьи об оптимизациях торговой системы на всех уровнях.
JVM предназначена для запуска широкого спектра Java-приложений. Для общего случая параметры, используемые JVM по умолчанию, вполне подойдут. Но если мы хотим добиться определенных результатов производительности, требуется тонкая настройка JVM с помощью определенных стартовых параметров.
Как видно из предыдущих статей JIT-компилятор на 4-ом уровне способен создавать высокопроизводительный нативный код. В некоторых случаях, благодаря сбору статистки в реальном рабочем окружении, нативный код получается даже лучше, чем код созданный статическим компилятором из исходников C/C++. Именно поэтому Java-программисты заявляют, что Java-приложение по скорости может превзойти приложение, написанное на C/C++.
Как же нам достичь этого уровня компиляции, если для его достижения требуется 15.000 исполнений?
