짧은 대기 시간 Java 작성 [닫기]


30

대기 시간이 짧은 코드를 Java로 작성하기위한 Java 관련 기술 (C ++에는 적용되지 않는 기술)이 있습니까? 나는 종종 낮은 대기 시간의 Java 역할을보고 대기 시간이 짧은 Java를 작성하는 경험을 요구합니다.

내가 생각할 수있는 유일한 생각은 JNI 경험, 네이티브 코드에 대한 I / O 호출 아웃소싱입니다. 또한 방해 요소 패턴을 사용할 수도 있지만 실제 기술은 아닙니다.

지연 시간이 짧은 코드를 작성하기위한 Java 관련 팁이 있습니까?

Real Time Java Spec이 있다는 것을 알고 있지만 실시간은 낮은 대기 시간과 같지 않다는 경고를 받았습니다 ....


수집주기를 유발할 수있는 개체를 너무 많이 만들지 않는 것이 제 추측 일 것입니다.
ratchet freak

@ratchet, 네트워크 또는 디스크 관련이 JNI 일 것이라고 생각합니까?
user997112

더 많은 링크와 프리젠 테이션을 원한다면 Performance Java User 's Group plus.google.com/u/1/communities/107178245817384004088
Peter Lawrey

안전하지 않은 직접 또는 간접적으로 sun.misc.를 사용하여 추가합니다. 많은 안전하지 않은 메소드는 고유 한 것으로 취급되므로 JNI를 피하는 머신 코드로 대체됩니다.
Peter Lawrey

주요 기술은 GC 오버 헤드를 완전히 피하는 것입니다. 이 기사에서 GC가없는 자바 개발
rdalmeida

답변:


35

Martijn의 의견 외에도 다음과 같이 덧붙입니다 .

  1. JVM을 예열하십시오. 바이트 코드는 핫스팟에 대한 해석을 시작한 다음 10K 관찰 후 서버에서 컴파일됩니다 . 계층 적 컴파일은 좋은 중지 간격이 될 수 있습니다.

  2. 클래스 로딩은 IO 대 디스크를 포함하는 순차적 프로세스입니다. 기본 트랜잭션 플로우에 대한 모든 클래스가 사전로드되어 있고 절대 파마 생성에서 제거되지 않아야합니다.

  3. " 단일 작가 원칙 "에 따라 Little 's Law의 경합과 큐잉 효과의 영향을 피하고 병행 할 수 있고 가치가있는 것에 대해 Amdhal의 법칙을 연구하십시오.

  4. 비즈니스 도메인을 모델링하고 모든 알고리즘이 O (1) 또는 최소한 O (log n)인지 확인하십시오. 이것은 아마도 내 경험에서 성능 문제의 가장 큰 원인 일 것입니다. 주요 사례를 다루기위한 성능 테스트가 있는지 확인하십시오.

  5. Java의 저 지연은 Java에만 국한되지 않습니다. 코드가 실행되는 전체 스택을 이해해야합니다. 여기에는 OS 조정, 적절한 하드웨어 선택, 해당 하드웨어에 대한 시스템 소프트웨어 및 장치 드라이버 조정이 포함됩니다.

  6. 현실적이 되십시오. 지연 시간이 짧은 경우 하이퍼 바이저에서 실행하지 마십시오. 실행 가능 상태에 있어야하는 모든 스레드에 충분한 코어가 있는지 확인하십시오.

  7. 캐시 미스는 성능에 가장 큰 비용입니다. 캐시 친화적 인 알고리즘을 사용하고 JVM의 경우 taskset 또는 numactl 또는 개별 스레드의 경우 JNI와 함께 프로세서 코어에 대한 선호도를 설정하십시오.

  8. 일시 정지없는 가비지 콜렉터가있는 Azul의 Zing과 같은 대체 JVM을 고려하십시오.

  9. 가장 중요한 것은 누군가가 경험에 참여하게하는 것입니다. 이렇게하면 장기적으로 많은 시간을 절약 할 수 있습니다. 뻔뻔한 플러그 :-)

실시간과 낮은 지연 시간은 종종 관련되어 있지만 분명히 별개의 주제입니다. 실시간은 빠른 것보다 더 예측 가능한 것입니다. 내 경험에 따르면 실시간 JVM, 심지어 부드러운 실시간 JVM도 일반 JVM보다 느립니다.


2
좋은 답변을 얻으려면 +1하십시오. 이와 같은 tx 처리 게시물에 관심이있는 사람은 연구를위한 훌륭한 출발점입니다.
mcfinnigan

23

알고 있어야 할 것들이 많이 있습니다. 나는 현재 인터넷 액세스가 제한되어있는 크레타 섬에있어서 (공평하게) 짧습니다. 또한, 나는 지연 시간이 짧은 전문가는 아니지만, 몇몇 동료들은 실생활에서 하나를합니다 :-).

  1. Mechanical Sympathy ( Martin Thompson이 만든 용어)에 감사해야합니다 . 다시 말해, 기본 하드웨어가하는 일을 이해해야합니다. CPU가 캐시 라인을로드하는 방법, 읽기 / 쓰기 대역폭, 주 메모리 속도 등을 아는 것이 훨씬 중요합니다. 왜? Java 소스 코드가 런타임 JVM을 통해 운영 체제 / 하드웨어에 어떤 영향을 미치는지 추론해야하기 때문입니다. 예를 들어, 소스 코드에 필드 변수가 배치되어 캐시 라인 제거 (~ 150 클럭 사이클 비용), hmmm ... :-)가 발생하는 방식입니다.

  2. 일반적으로 잠금없는 알고리즘과 I / O를 원합니다. (잠금을 사용하는) 가장 잘 설계된 동시 응용 프로그램조차도 차단 위험이 있으며 낮은 대기 시간으로 차단하는 것은 일반적으로 좋지 않습니다 :-).

  3. 객체 할당 및 가비지 수집 이해 이 주제는 방대한 주제이지만 기본적으로 GC 일시 중지를 피하려고합니다 (종종 다양한 GC 컬렉션의 세계 중지 특성으로 인해 발생 함). Azul 수집기와 같은 전문가 GC 수집기는 많은 경우이 문제를 즉시 해결할 수 있지만 대부분의 사람들은 Sun / Oracle GC (CMS, G1 등)를 조정하는 방법을 이해해야합니다.

  4. 핫스팟 JIT는 놀랍습니다. 최적화에 대해 배우지 만 일반적으로 모든 훌륭한 OO 기술 (캡슐화, 작은 메소드, 가능한 한 많은 불변 데이터)을 사용하면 JIT가 최적화되어 C / C ++ 코드로 잘 만들어진 성능 수준을 얻을 수 있습니다.

  5. 전체 시스템 아키텍처. 광섬유 등을 통해 교환기에 연결된 경우 네트워크, 기계의 배치 방법을 알고 있어야합니다.

  6. 로깅의 영향에 유의하십시오. 바이너리를 로깅하거나 오프라인으로 구문 분석 할 수있는 코딩 된 출력을 사용하는 것이 좋습니다.

전반적으로 Kirk Pepperdine의 Java Performance Tuning 과정을 진행할 것을 적극 권장합니다. [면책 조항 :이 과정을 스스로 가르치므로 편견입니다.] JVM의 다양한 측면과 기본 O / S 및 하드웨어에 미치는 영향에 대해 잘 설명합니다.

추신 : 나중에 다시 방문하고 정리하려고합니다.


Mechanical Sympathy를 경험 한 사람들이 주어진 경계를 넘었을 때이를 감지하기위한 몇 가지 트릭을 공유 할 수 있다면 정말 좋을 것입니다.

나는 시도하고 :-)에 진짜 전문가를 얻기 위해 트위터 핑 한
Verburg 마티

쿨, 마틴 톰슨은 내 조언을 따를 가치가있다.
마티 Verburg
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.