Java 잠금 없는 동시성

Question

다음 코드에서 잠금 해제 및 잠금 비율이 더 나은 구현인가요? jmeter를 사용하여 초당 20개의 요청을 수행합니다. 잠금 없는 코드 실행에서 절전 작업의 출력은 대부분 500밀리초와 크게 다르지만 잠긴 코드의 출력은 기본적으로 1 또는 1의 차이로 500밀리초입니다. 2밀리초.. 참 이상하네요....test() 으아악

Answer 1

1. 우선 두 가지 문제를 명확히 하겠습니다. 일반적으로 AtomicXX 클래스와 비교되지 않지만 ReentrantLock 클래스에는 더 많은 비교가 있으므로 직접 Google에서 검색할 수 있습니다.

2. 잠금 없음 또는 잠금에 대한 질문과 관련하여 테스트 코드 b의 코드에 문제가 있습니다.

• 동기화된 코드 블록의 경우 첫 번째 수신 스레드가 잠금을 보유한 후 잠금 획득을 요청하는 후속 스레드가 차단되고 일시 중단됩니다. 이전 스레드가 잠금을 해제할 때까지 후속 스레드가 실행을 재개합니다. 잠금이 존재하므로 20개의 요청은 순차적 실행과 유사합니다, 이 레이어는 jvm

에 의해 예약됩니다.

• 메서드 b의 경우 cas 작업은 실제로는 항상 실행 중입니다(계속해서 cas 작업 수행을 시도함). 우리는 무한 루프가 CPU 리소스를 더 많이 소비한다는 것을 알고 있습니다. 스레드가 많을수록 CAS 작업이 많아져 필연적으로 CPU 사용량이 급증하게 됩니다. 메소드 B의 코드를 jmeter로 테스트할 때 이론적으로는 항상 20개의 활성 작업 스레드가 있어야 합니다. CPU 및 스레드 모델은 또 다른 주제입니다. , 스레드 번호 조정은 jvm에서 비교적 고급 주제입니다. 관심이 있으시면 직접 구글링해 보세요

• ReentrantLock 및 동기화에 대해 이야기해 보겠습니다. 일반적으로 동시성이 높을 때 ReentrantLock은 동기화보다 성능이 더 좋으며 ReentrantLock은 동기화가 제공하지 않는 일부 기능을 제공합니다(잠금 시간 초과 자동 포기 등은 샘플 코드에서 줄일 수 있음). 500ms는 인간에게는 매우 짧은 시간이지만, 기본적으로는 "달팽이처럼 느리다"고 표현해도 과언이 아닙니다. 예. 코드:

으아아아

• 방법 c는 ReentrantLock을 사용하여 구현됩니다. 대부분의 경우 ReentrantLock이 동기화된 것보다 더 효율적입니다

• juc(java.util.concurrent)의 핵심 클래스 Aqs(AbstractQueuedSynchronizer)는 대기열 기반 동시성 패키지입니다. 기본적으로 잠금 경쟁(스핀)이 1000나노초를 초과하면 스레드가 정지됩니다(작업 일시 중지). CPU의 빈번한 스레드 전환을 줄이기 위해 방법 c에서 절전 시간 매개변수를 조정해 볼 수 있습니다.

• 테스트 방법, 이 시스템에는 jmeter가 설치되어 있지 않습니다. 테스트는 apache ab로 수행됩니다. 테스트 명령:

으아아아