가비지 수집기를 제외하고 Java를 비 실시간 프로그래밍 언어로 만드는 다른 요소


28

가비지 수집기를 제외하고 Java에서 실시간 프로그래밍에 적합하지 않은 다른 기능은 무엇입니까? 인터넷에서 실시간 프로그래밍과 관련하여 Java vs C ++가 논의 될 때마다 항상 언급 된 가비지 수집기입니다. 다른 것이 있습니까?


4
가비지 수집조차도 문제가되지 않습니다. 사용 가능한 몇 가지 어려운 실시간 가비지 수집기가 있습니다. gc를 실시간으로 쇼 스토퍼로 언급하는 사람들은 단순히 무능합니다.
SK-logic

2
@ SK-logic s / incompetent / uninformed / g
Scott Whitlock

@ScottWhitlock은 동의했다. 그러나 일부 (가장 큰 목소리)는 제대로 정보를받은 후에도 계속 주장합니다. 나는이 인류 학적 현상에 대한 합리적인 설명을 모른다.
SK-logic

답변:


36

직접 기억할 수있는 두 가지 추가 항목이 있습니다.

  1. JIT 컴파일
  2. 스레딩 구현

실시간 측면에서 성능의 예측 가능성은 아마도 가장 중요한 요소 일 것입니다. 그렇기 때문에 예측할 수없는 GC 주기로 인해 Java가 실시간에 적합하지 않습니다.

JIT는 향상된 성능을 제공하지만 프로그램이 실행 된 후 어느 시점에서 시작되어 일부 리소스를 사용하고 시스템의 실행 속도를 변경합니다. VM이 그 시점에서 "더 나은"작업을 수행 할 수 있다고 믿는 경우 나중에 다시 발생할 수도 있습니다.

스레딩에 관해서는 :이 시점에서 언어 디자인의 일부이거나 매우 일반적인 구현인지는 기억하지 못하지만 Java는 일반적으로 스레드 실행을 정확하게 제어하는 ​​도구를 제공하지 않습니다. 예를 들어 스레드에 10 개의 "우선 순위"가 지정되어 있지만 VM이 실제로 이러한 우선 순위를 고려할 필요는 없습니다. 스레드 정지 및 전환을위한 연산자도 정의되지 않았거나 시스템에 의해 엄격하게 준수되지 않습니다.

JSR 1 : Real-time Specification for Java -1998 년에 승인 된 사양 이 여러 가지 구현 되어 있습니다.이 사양은 표준 Java를 실시간으로 부적합하게 만드는 문제를 가능한 많이 해결합니다.

아마도 5 년 전쯤 Sun (현재 Oracle)은 RTSJ VM을 가지고있었습니다 (AFAIK라는 이름은 없었습니다). IBM은 WebSphere Real Time을 가지고있었습니다. 그리고 JamaicaVM은 무료 (?) 플랫폼 독립적 솔루션이었습니다. 오늘날 사람들을 인터넷 검색하는 것은별로 도움이되지 않습니다.


비록 작은 비교이지만, 또 다른 문제는 클래스가 사용될 때만로드된다는 것입니다.
T-Bull

5
Java 스펙에는 AOT 또는 순수한 해석 대신 JIT를 시행 할 것이 없습니다. 순수한 녹색 스레드는 완전히 예측 가능하므로 실시간 장애물이 될 수 없습니다.
SK-logic

websphere 실시간은 최소한 여전히 지원되는 것 같습니다 (Java 7.0 지원을 요구하고이를 구매하려면 페이지를 방문하십시오)
jk.

@ SK-logic-맞습니다, 좋은 지적입니다!
aviv

33

운영 체제

Java가 Unix 또는 Windows 또는 기타 "일반"OS에서 실행되는 한 실시간은 보장되지 않습니다.

실시간 응용 프로그램을 실행하려면 실시간 OS가 필수입니다.


13
@Giorgio : 어려운 실시간 보장을 위해? 예.
Joachim Sauer

5
또한 처음부터 실시간으로 설계된 사용 가능한 운영 체제가 있습니다 (예 : FreeRTOS).
medivh 2016 년

4
이것은 일반적으로 어려운 실시간에는 매우 중요한 점이지만, 조금이라도 Java 고유의 ​​것으로 보이지는 않습니다. 뭔가 빠졌습니까?

3
@delnan 요점은 (가상?) Java VM의 실시간 구현을 사용하더라도 OS가 실시간 보장을 제공 할 수 없다면 크게 도움이되지 않습니다.
schlingel 2016 년

3
@delnan-이 질문에는 C ++이 실시간 프로그래밍 언어라는 잘못된 주장이 있습니다.
mouviciel 2016 년

7

기술적으로 실시간 자바를 가질 수 있습니다 (SK-logic의 의견에서 알 수 있듯이). 그러나 여러 가지 비 기술적 인 이유로 일반적이지 않습니다.

오래된 표준

이것에 대한 참조를 찾는 데 문제가 있지만 안전 표준 또는 안전 표준 준수 조언을 보았을 때 Java에 대한 담요 금지를했다고 확신합니다. Java가 verboten이라는 말을 준수 해야하는 경우 옳고 그름은 Java가 Verboten입니다.

오래된 안전 엔지니어

Java를 금지하지 않기 위해 노력해야하는 표준이 있더라도 Java에 대한 경험이없는 안전 / 품질 감사관과 함께 작업하면 저항이 가장 적은 경로를 따르지 않는 것입니다. 감사인에게 평범하지 않은 것은 많은 질문을 불러 일으킬 것이며, 이는 선택을 정당화하기위한 많은 일을 의미합니다.

커뮤니티

즉, 많은 경로 의존성이 있으며, 현재의 실시간 전문가 대부분은 C ++, C 또는 ADA를 알고 있으므로 새로운 작업을하는 것이 당연한 선택입니다.

(참고 : 위의 경우 다소 안전하고 평범한 것으로 나타났습니다. 안전 표준조차도 종종 두 가지를 상충한다는 점에서 또 다른 문제입니다.)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.