Приложение управления задержки ~1s: действительно ли это подходит для Java?
На моей работе мы недавно закончили архитектуру системы для приложения управления, которое имеет максимальную задержку примерно одной - двух секунд. Это распределяется на маленьком ARM поля на микросхеме, связывающиеся через IP LAN.
Мы первоначально предвидим, что использовали бы C или C++, так как это - классический язык системы управления. После обсуждения, как реализовать приложение, мы теперь понимаем, что C++ имеет довольно ограниченное количество библиотек, испытывает недостаток в самоанализе и имеет некоторые другие свойства, которые могли бы замедлить разработку. Мой коллега затем предположил, что Java мог бы подлежать заданию.
Я действительно боюсь о задержке выполнения GC для приложения управления, и я также отказываюсь отбросить RAII, так как приложение будет использовать много внешних ресурсов (сокеты, дескрипторы файлов, дескрипторы от внешнего освобождает и т.д.).
Про/обманный список в настоящее время следующие:
C++
+ RAII - Easy resource management - it will be a complex system
+ System language - speed if we cant't find a JIT VM for our ARM
+ No GC - no big worst case latencies from the GC
+ Easy to integrate with some shared mem libs that we have to interface with
- Fewer free as in beer libs
- Lacks introspection - Mapping classes to DB and external data formats (XML)
would benefit from this (ORM /JAXB) approach
- Easy to shoot one self in the foot - hard and expensive to find programmers
which don't make big mistakes
- Memory fragmentation - needs tuning and workarounds
Java
+ Huge amount of libs
+ Introspection - serialization becomes a breeze (see C++ section)
+ Easier to find 'good enough' programmers
- No RAII - Client has to remember finally or you leak
resources. IMO Java programmers tend to ignore this
problem unless they have server app background.
- No System Language - possibly slower although ARMj could alleviate this
- GC - latency might go up (don't know if parallel GC will work - seems that
you might get fragmentation, see note below).
- Need to write JNI for the shared mem libs that we interface with
- Maybe ORACLE will eat us
Фрагментация памяти с параллельным GC была упомянута в этой статье AMD
Я хотел бы использовать Java, если задержка GC не была проблемой, и мы могли бы получить RAII. Поэтому я также изучил другие langs, которые имеют RAII и могли служить хорошими альтернативами, и до сих пор я нашел, что у D, Ada, VB, Perl, Python (C), PHP, tcl и Lua, кажется, есть своего рода обратный вызов из объема. Моя spontainous реакция, что, возможно, D, Python и ADA мог подойти для приложения управления. D и ADA являются моими фаворитами.
Так, мой вопрос: у Вас есть какие-либо рекомендации на этом? Действительно ли Java является жизнеспособным вариантом, и если бы Вы могли бы выбрать какой-либо язык, каково это было бы?
3 ответа
GC используется только для возврата памяти из отброшенных объектов. Выбрасывайте очень мало ресурсов, и вы получите очень маленькие и короткие GC.
Вы можете использовать множество сокетов, файловых дескрипторов, дескрипторов внешних библиотек, но как быстро вы их отбрасываете?
Полный GC предназначен для устранения фрагментации. Он делает это, копируя всю память так, чтобы она использовалась непрерывно. Вот почему он дорогой, поэтому вы хотите минимизировать его, если для вас важна задержка. Тем не менее, если ваши полные GC занимают более 100 мс, у вас серьезные проблемы с производительностью. Она не должна быть такой высокой.
IMHO, я считаю, что вы должны быть в состоянии разработать систему управления с задержкой менее 10 мс в 99%+ случаев.
Вероятно, вам нужно доказательство концепции, если вы хотите использовать java, я бы предложил написать простой прототип и стресс-тест, чтобы проверить, какое время задержки у вас есть при высокой нагрузке во время сборки мусора. Затем проверьте различные типы коллекторов, например, коллектор с низкой паузой.
Аргумент RAII я не очень понимаю,в C++ ИМХО проще создавать утечки памяти, чем в java.
Я бы держался подальше от GC (конечно, как это реализовано в любой JVM, которую я видел) в такой среде. Вы всегда будете биться головой о стену о проблеме.
Тем не менее, я просто хотел указать, что аргумент RAII кажется очень слабым - вам нужны обзоры кода и другое подобное обучение, чтобы гарантировать, что такие вопросы хорошо понимаются вашей командой. Это очень плохая причина для исключения языка, который в остальном подходит, поскольку у каждого языка есть подводные камни, которые неопытный / менее звездный программист может пропустить.
Из вашего списка я почувствовал, что вам не хватает C # (я думаю о Mono), где у вас гораздо больше контроля, когда он вам нужен. Я не знаю, подходит ли это для вашей среды, но если вы включите VB в свой подробный список языков, это будет очевидная оплошность.