Каковы причины того, почему стек Java / Linux не может быть «в реальном времени»?

Я часто слышал, как разработчики упоминали, что Java не может « делать в реальном времени », то есть приложение Java, работающее в Linux, не может отвечать требованиям детерминированной системы реального времени, такой как что-то, работающее в RIOT-OS и т. Д.

Я пытаюсь понять, почему . Моя SWAG говорит мне, что это, вероятно, во многом благодаря сборщику мусора Java, который может работать в любое время и полностью останавливать систему. И хотя существуют так называемые «бессмысленные сборщики мусора», я не обязательно верю их рекламе, а также не имею $ 80K за JVM-экземпляр, который можно раскошелиться на хобби-проект!

Я также читал эту статью о запуске программного обеспечения дронов в Linux . В этой статье автор описывает сценарий, когда Linux чуть не врезался в его дрон:

Я усвоил тяжелый урок после того, как решил сделать цикл управления низкого уровня (PID) на Pi - пытаясь быть умным, я решил поместить запись журнала в середину цикла для отладки - квадроцикл изначально работал нормально, но затем Linux решил заняло 2 секунды, чтобы написать одну запись в журнале, и квад почти врезался в мою машину!

Теперь, хотя этот автор написал свое программное обеспечение для дронов на C ++, я бы предположил, что Java-приложение, работающее на Linux, вполне может постигнуть та же участь.

Согласно Википедии:

О системе говорят, что она работает в режиме реального времени, если полная корректность операции зависит не только от ее логической правильности, но также и от времени, в которое она выполняется.

Так что для меня это означает: « У вас нет реального времени, если полная корректность требует логической корректности и своевременности ».

Давайте представим, что я написал Java-приложение для супер производительности, и что я «сжал лимон», так сказать, и его нельзя было написать (на Java), чтобы быть быстрее.

В общем, мой вопрос: я ищу кого-то, кто объяснит мне все / большинство причин, почему приложение Java, работающее под Linux, не может быть «приложением реального времени». Имеется в виду, что все категории вещей в стеке Java / Linux препятствуют тому, чтобы он был «своевременным» и, следовательно, « абсолютно правильным »? Как уже упоминалось, похоже, что очистка журналов в GC и Linux может приостановить выполнение, но я уверен, что помимо самого приложения Java есть и другие вещи, которые могут привести к плохой синхронизации / производительности и привести к жестким ограничениям сроков. Кто они такие?

Программное обеспечение работает в режиме реального времени не тогда, когда оно работает максимально быстро, а когда гарантируется, что процесс завершается в течение определенного периода времени. В мягкой системе реального времени это хорошо, но не обязательно, что это гарантировано. Например, в игре вычисления, необходимые для кадра, должны быть выполнены в течение периода кадра, иначе частота кадров упадет. Это ухудшает качество игрового процесса, но не делает его некорректным. Например, Minecraft доставляет удовольствие, хотя игра иногда заикается.

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

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

Кроме того, программа пользовательского пространства будет выполнять системные вызовы в ядро. В ОС реального времени они тоже должны быть в режиме реального времени. Например, запись в дескриптор файла должна гарантированно занимать не более x единиц времени, что решит проблему с журналом. Это влияет на то, как такой системный вызов может быть реализован, например, как могут использоваться буферы. Это также означает, что вызов должен завершиться неудачей, если он не может быть завершен в течение требуемого времени, и что программа пользовательского пространства должна быть готова к работе с этими случаями. В случае Java JVM и стандартная библиотека также похожи на ядра и требуют явной поддержки в реальном времени.

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

Из википедии :

Ключевой характеристикой ОСРВ является уровень ее согласованности относительно количества времени, которое требуется для принятия и выполнения задачи приложения; изменчивость джиттер.

Важно то, что джиттер определяется количественно, чтобы система считалась в реальном времени . Далее в статье говорится, что если дрожание обычно ограничено, система работает в режиме реального времени . Если дрожание всегда ограничено, система работает в режиме реального времени .

Если версии Java и Linux, которые вы используете, не определены количественно с точки зрения джиттера, они не отображаются в реальном времени. Сборка мусора и запись в журнал, безусловно, являются источниками дрожания, но даже автономная обработка (например) сетевых пакетов имеет значение, если она вносит дрожание в ваши процессы.

Для начала, сам по себе ванильный Linux не может работать в режиме реального времени. Вот почему RTLinux был разработан.

Допустим, вы запускаете несколько java-процессов в RTLinux, они все равно будут рассматриваться в режиме реального времени, так как все эти процессы запланированы ядром, то есть если один процесс запаздывает, другие процессы по-прежнему могут иметь гарантированную долю времени процессора.

Теперь, если процессы Java запускают потоки Green , выполнение этих потоков больше не будет выполняться в реальном времени, поскольку JVM не выполняет планирование в реальном времени.