가비지 수집기를 제외하고 Java에서 실시간 프로그래밍에 적합하지 않은 다른 기능은 무엇입니까? 인터넷에서 실시간 프로그래밍과 관련하여 Java vs C ++가 논의 될 때마다 항상 언급 된 가비지 수집기입니다. 다른 것이 있습니까?
가비지 수집기를 제외하고 Java에서 실시간 프로그래밍에 적합하지 않은 다른 기능은 무엇입니까? 인터넷에서 실시간 프로그래밍과 관련하여 Java vs C ++가 논의 될 때마다 항상 언급 된 가비지 수집기입니다. 다른 것이 있습니까?
답변:
직접 기억할 수있는 두 가지 추가 항목이 있습니다.
실시간 측면에서 성능의 예측 가능성은 아마도 가장 중요한 요소 일 것입니다. 그렇기 때문에 예측할 수없는 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은 무료 (?) 플랫폼 독립적 솔루션이었습니다. 오늘날 사람들을 인터넷 검색하는 것은별로 도움이되지 않습니다.
Java가 Unix 또는 Windows 또는 기타 "일반"OS에서 실행되는 한 실시간은 보장되지 않습니다.
실시간 응용 프로그램을 실행하려면 실시간 OS가 필수입니다.
기술적으로 실시간 자바를 가질 수 있습니다 (SK-logic의 의견에서 알 수 있듯이). 그러나 여러 가지 비 기술적 인 이유로 일반적이지 않습니다.
오래된 표준
이것에 대한 참조를 찾는 데 문제가 있지만 안전 표준 또는 안전 표준 준수 조언을 보았을 때 Java에 대한 담요 금지를했다고 확신합니다. Java가 verboten이라는 말을 준수 해야하는 경우 옳고 그름은 Java가 Verboten입니다.
오래된 안전 엔지니어
Java를 금지하지 않기 위해 노력해야하는 표준이 있더라도 Java에 대한 경험이없는 안전 / 품질 감사관과 함께 작업하면 저항이 가장 적은 경로를 따르지 않는 것입니다. 감사인에게 평범하지 않은 것은 많은 질문을 불러 일으킬 것이며, 이는 선택을 정당화하기위한 많은 일을 의미합니다.
커뮤니티
즉, 많은 경로 의존성이 있으며, 현재의 실시간 전문가 대부분은 C ++, C 또는 ADA를 알고 있으므로 새로운 작업을하는 것이 당연한 선택입니다.
(참고 : 위의 경우 다소 안전하고 평범한 것으로 나타났습니다. 안전 표준조차도 종종 두 가지를 상충한다는 점에서 또 다른 문제입니다.)