Oprócz śmietnika, co jeszcze sprawia, że ​​Java nie jest językiem programowania w czasie rzeczywistym


28

Z wyjątkiem modułu wyrzucania elementów bezużytecznych, jakie są inne funkcje Java, które sprawiają, że nie nadaje się do programowania w czasie rzeczywistym? W sieci, ilekroć omawia się Javę kontra C ++ w odniesieniu do programowania w czasie rzeczywistym, zawsze wspomina się o śmieciarzu. Czy jest coś jeszcze?


4
Nawet wyrzucanie śmieci nie stanowi problemu - dostępnych jest kilka twardych śmieciarek w czasie rzeczywistym. Ci, którzy wspominają gc jako ogranicznik show w czasie rzeczywistym, są po prostu niekompetentni.
SK-logic

2
@ SK-logic s / niekompetentny / niedoinformowany / g
Scott Whitlock

@ScottWhitlock, uzgodniono, większość z nich jest. Ale niektórzy (najbardziej głośni) nalegają, nawet po odpowiednim poinformowaniu. Nie znam żadnego racjonalnego wyjaśnienia tego antropologicznego zjawiska.
SK-logic

Odpowiedzi:


36

Są dwa dodatkowe przedmioty, które pamiętam z ręki:

  1. Kompilacja JIT
  2. Implementacja wątków

W kontekście czasu rzeczywistego przewidywalność wydajności jest prawdopodobnie najważniejszym czynnikiem; Dlatego nieprzewidywalny cykl GC sprawia, że ​​Java nie nadaje się do pracy w czasie rzeczywistym.

JIT oferuje lepszą wydajność, ale uruchamia się w pewnym momencie po uruchomieniu programu, zabierając część zasobów i zmieniając szybkość wykonywania systemu. Może się to zdarzyć ponownie na późniejszym etapie, jeśli maszyna wirtualna uważa, że ​​w tym czasie może wykonać „lepszą” pracę.

Jeśli chodzi o wątki: nie do końca pamiętam, czy jest to część projektu języka, czy tylko bardzo powszechna implementacja, ale Java zwykle nie zapewnia narzędzi do precyzyjnej kontroli wykonywania wątków; Na przykład, chociaż dla wątków określono 10 „priorytetów”, nie ma wymogu, aby maszyna wirtualna faktycznie uwzględniała te priorytety. Operatory zatrzymujące i przełączające wątki również nie są zdefiniowane lub nie są ściśle przestrzegane przez system.

Istnieje kilka implementacji JSR 1: Specyfikacja w czasie rzeczywistym dla Java - specyfikacja zatwierdzona w 1998 r. Ta specyfikacja rozwiązuje w jak największym stopniu problemy, które sprawiają, że standardowa Java nie nadaje się do pracy w czasie rzeczywistym.

Być może 5 lat temu Sun (teraz Oracle) miał maszynę wirtualną RTSJ (która nigdy nie miała nazwy, AFAIK); IBM miał WebSphere Real Time; A JamaicaVM było darmowym (?) Niezależnym od platformy rozwiązaniem. Googlowanie dzisiaj nie przynosi wiele.


Inną kwestią, choć niewielką w porównaniu, jest to, że klasa jest ładowana tylko wtedy, gdy będzie używana.
T-Bull

5
W specyfikacji Java nie ma nic, co wymusiłoby JIT zamiast AOT lub czystej interpretacji. Czysto zielone nici są całkowicie przewidywalne, więc nie mogą być przeszkodą w czasie rzeczywistym.
SK-logic

websphere w czasie rzeczywistym przynajmniej wydaje się być obsługiwany (twierdzi, że obsługuje Java 7.0 i możesz przejść do strony, aby go kupić)
jk.

@ SK-logic - racja, dobra uwaga!
aviv

33

System operacyjny

Tak długo, jak Java działa na Uniksie, Windowsie lub jakimkolwiek innym „zwykłym” systemie operacyjnym, nie można zagwarantować działania w czasie rzeczywistym.

System operacyjny w czasie rzeczywistym jest obowiązkowy do uruchamiania aplikacji w czasie rzeczywistym.


13
@Giorgio: dla twardych gwarancji w czasie rzeczywistym? Tak.
Joachim Sauer

5
Ponadto istnieją dostępne systemy operacyjne, które od samego początku są zaprojektowane dla czasu rzeczywistego, np. FreeRTOS.
medivh

4
Chociaż jest to bardzo ważna kwestia w trudnym czasie w ogóle, wydaje się, że nie jest specyficzna dla Javy. Czy coś brakuje?

3
@ delnan chodzi o to, że nawet jeśli używasz (wyobrażonej?) implementacji maszyny wirtualnej Java w czasie rzeczywistym, to nie pomaga, jeśli system operacyjny nie może dać Ci gwarancji w czasie rzeczywistym.
schlingel

3
@delnan - Pytanie ma fałszywe założenia, co sugeruje, że C ++ jest językiem programowania w czasie rzeczywistym.
mouviciel

7

Technicznie możliwe jest posiadanie java w czasie rzeczywistym (jak sugerują komentarze SK-logic). jednak nie jest to powszechne z wielu nietechnicznych powodów:

Stare standardy

Mam problem ze znalezieniem referencji na ten temat, ale jestem pewien, że widziałem standardy bezpieczeństwa lub porady dotyczące zgodności ze standardami bezpieczeństwa, wprowadziły ogólny zakaz Java. Słusznie lub nie, jeśli musisz dostosować się do czegoś, co mówi, że Java jest werbalna, wówczas Java jest werbalna.

Starzy inżynierowie bezpieczeństwa

Nawet jeśli standardy, które musisz podjąć, aby nie blokować Javy, praca z audytorami bezpieczeństwa / jakości bez doświadczenia w Javie w dużym stopniu oznacza, że ​​nie podążasz ścieżką najmniejszego oporu. Wszystko, co jest nietypowe dla audytora, prawdopodobnie przyciągnie wiele pytań, co z kolei oznacza wiele pracy dla ciebie uzasadniającej twój wybór.

Społeczność

tzn. istnieje duża zależność od ścieżki, większość obecnych ekspertów w czasie rzeczywistym zna C ++, C lub ADA na wylot, więc jest to naturalny wybór, aby wykonać nową pracę.

(uwaga: w pewnym stopniu połączyłem w czasie rzeczywistym i bezpieczeństwo, co jest poniekąd inną kwestią, ponieważ nawet normy bezpieczeństwa często łączą te dwa elementy)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.