Java / Linux 스택이 "실시간"이 아닌 이유는 무엇입니까?

필자는 개발자들이 자바가 " 실시간으로 할 수 없다" 는 말을 자주 들었다 . 리눅스에서 실행되는 자바 앱이 RIOT-OS에서 실행되는 것과 같은 결정적인 실시간 시스템의 요구 사항을 충족 할 수 없다는 의미이다.

이유 를 이해하려고 노력하고 있습니다. 내 SWAG에 따르면 이는 아마도 언제든지 실행되고 시스템을 완전히 일시 중지 할 수있는 Java 가비지 수집기 때문일 것입니다. 소위 "일시 정지없는 GC"가 있지만 광고를 믿지 않아도되고 취미 프로젝트를 위해 JVM 당 $ 80K를 지불하지 않아도됩니다.

또한 Linux에서 드론 소프트웨어를 실행하는 방법에 대한이 기사를 읽고있었습니다 . 이 기사에서 저자는 리눅스가 드론을 거의 차에 충돌시키는 시나리오를 설명합니다.

Pi에서 로우 레벨 제어 루프 (PID)를 선택한 후 어려운 교훈을 얻었습니다. 영리하려고 노력했습니다. 디버깅을 위해 루프 중간에 로그 쓰기를하기로 결정했습니다. 쿼드는 처음에는 잘 뛰었지만 Linux는 결정했습니다. 하나의 로그 항목을 작성하는 데 2 ​​초가 걸리고 쿼드가 내 차에 거의 추락했습니다!

저자가 C ++로 드론 소프트웨어를 작성했지만 Linux에서 실행되는 Java 앱이 동일한 운명을 겪을 수 있다고 생각합니다.

Wikipedia에 따르면 :

작업의 전체 정확성이 논리적 정확성뿐만 아니라 수행 시간에 의존하는 경우 시스템은 실시간이라고합니다.

그래서 나에게,이 의미는 " 총 정확성은 논리적 정확성과 적시성을 필요로하는 경우는 실시간이 없습니다. "

내가 최고 성능을 발휘할 수있는 Java 앱을 작성했다고 말하고 말하기 위해 "레몬을 압착"했다고 말하고 합리적으로 (Java로) 더 빨리 쓸 수는 없다고 가정 해 봅시다.

대체로, 제 질문은 : 누군가 n Linux를 실행하는 Java 앱이 "실시간 앱"이 아닌 이유를 모두 설명해 줄 사람을 찾고 있습니다. 즉, Java / Linux 스택에서 "적시"가되지 않아 " 완전히 올바른 "상태 가되는 것을 방지하는 모든 범주의 범주는 무엇 입니까? 언급했듯이 GC 및 Linux 로그 플러싱이 실행을 일시 중지 할 수있는 것처럼 보이지만 Java 앱 자체 외부에 타이밍 / 성능이 저하되고 마감 기한을 충족시키는 더 많은 것들이 있다고 확신합니다. 그들은 무엇인가?

소프트웨어는 가능한 한 빠른 것이 아니라 프로세스가 정해진 시간 내에 완료 될 때 실시간입니다. 소프트 실시간 시스템에서는 이것이 보장되는 것이 좋지만 반드시 필요한 것은 아닙니다. 예를 들어 게임에서 프레임에 필요한 계산은 프레임 기간 내에 완료되어야합니다. 그렇지 않으면 프레임 속도가 떨어집니다. 이것은 게임 플레이의 품질을 떨어 뜨리지 만 잘못하지는 않습니다. 예를 들어 게임이 가끔 더듬 거리더라도 Minecraft는 즐겁습니다.

어려운 실시간 시스템에서는 그러한 자유가 없습니다. 비행 제어 소프트웨어는 기한 내에 반응해야합니다. 그렇지 않으면 차량이 충돌 할 수 있습니다. 또한 하드웨어, OS 및 소프트웨어가 함께 작동하여 실시간을 지원해야합니다.

예를 들어, OS에는 실행되는 스레드를 결정하는 스케줄러가 있습니다. 실시간 프로그램의 경우 스케줄러는 충분히 크고 자주 충분한 시간 슬롯을 보장해야합니다. 이러한 슬롯에서 실행하려는 다른 프로세스는 실시간 프로세스를 위해 중단되어야합니다. 이를 위해서는 명시적인 실시간 지원 스케줄러가 필요합니다.

또한 사용자 공간 프로그램은 시스템 호출을 커널로 수행합니다. 실시간 OS에서는 이것들도 실시간이어야합니다. 예를 들어, 파일 핸들에 쓰는 것은 x 시간 단위를 초과 하지 않도록 보장해야 하므로 로그 문제가 해결됩니다. 이는 시스템 호출을 구현하는 방법, 예를 들어 버퍼 사용 방법에 영향을줍니다. 또한 필요한 시간 내에 호출을 완료 할 수 없으면 호출이 실패해야하며 사용자 공간 프로그램이 이러한 경우를 처리 할 준비가되어 있어야합니다. Java의 경우 JVM 및 표준 라이브러리도 커널과 유사하며 명시적인 실시간 지원이 필요합니다.

실시간 인 경우 프로그래밍 스타일이 변경됩니다. 끝없는 시간이 없다면 작은 문제로 자신을 제한해야합니다. 모든 루프는 일정한 상수로 묶어야합니다. 크기에 대한 상한이 있으므로 모든 메모리를 정적으로 할당 할 수 있습니다. 무제한 재귀는 금지되어 있습니다. 이것은 많은 모범 사례에 위배되지만 실시간 시스템에는 적용되지 않습니다. 예를 들어, 로깅 시스템은 정적으로 할당 된 링 버퍼를 사용하여 로그 메시지가 기록 될 때이를 저장합니다. 시작에 도달하면 이전 로그가 삭제되거나이 조건이 오류 일 수 있습니다.

에서 위키 피 디아 :

RTOS의 주요 특징은 응용 프로그램 작업을 수락하고 완료하는 데 걸리는 시간과 관련된 일관성 수준입니다. 변동성은 지터입니다.

중요한 것은 시스템이 실시간으로 고려되도록 지터가 정량화된다는 것입니다 . 이 기사에서는 지터가 일반적으로 경계가있는 경우 시스템이 실시간 이라고 말합니다 . 지터가 항상 경계인 경우 시스템은 실시간으로 단단합니다 .

사용하는 Java 및 Linux 버전이 지터로 수량화 되지 않으면 실시간 이 아닙니다 . 그것으로 지터를 도입하면 쓰레기 수집 및 로그 쓰기는 확실히 지터의 소스,하지만 (예를 들어) 네트워크 패킷 카운트도 자율적 처리하는 당신의 프로세스.

우선, 바닐라 리눅스 자체는 실시간으로 할 수 없습니다. 이것이 RTLinux 가 개발 된 이유 입니다.

RTLinux에서 몇 개의 Java 프로세스를 실행한다고 가정 해 봅시다. 모든 프로세스가 커널에 의해 예약되므로 실시간으로 간주됩니다. 즉, 한 프로세스가 늦어도 다른 프로세스는 여전히 CPU 시간 조각을 가질 수 있습니다.

이제 Java 프로세스가 Green threads 를 실행하면 JVM이 실시간 스케줄링을 수행하지 않기 때문에 이러한 스레드의 실행이 더 이상 실시간이 아닙니다.