大家讲道理2017-04-18 10:39:44
디자인에 따르면 ThreadLocal
은 Thread
의 존재에 따라 존재해야 합니다. 각 스레드는 저장 공간을 가질 수 있으므로 두 번째 요점에 대해서는 매우 동의합니다. 이해할 수 있는.
디자인에 따라 map
에 ThreadLocal
을 넣으면 이 map
는 static
(또는 ThreadLocal
싱글톤의 멤버 변수)에 속해야 하며 이는 디자인에 심각한 문제를 일으킬 수 있습니다. . , 이 map
는 관리하기가 매우 어려울 것입니다:
디자인에는 일련의 방법과 철학이 있으므로 신중하게 음미해야 합니다.
黄舟2017-04-18 10:39:44
적어도 제가 생각할 수 있는 한 가지는:
상호 배제 비용 절감
다음 시나리오가 있습니다. DateFormat의 성능을 향상시키기 위해 일반적으로 ThreadLocal과 결합됩니다.
怪我咯2017-04-18 10:39:44
일부 디자인은 때로는 성능만을 위한 것이 아닙니다. Java는 디자인 패턴에 가장 많은 관심을 기울이고 있으며 단일 책임은 디자인 패턴의 가장 중요한 원칙 중 하나라는 것을 알아야 합니다.
반면에 Map을 직접 사용하는 것보다 ThreadLocal에서 직접 Map을 구현하는 것이 더 빠르지 않을까요? 하지만 이는 분명히 단일 책임을 위반하고 유지 관리 비용이 더 많이 듭니다.
迷茫2017-04-18 10:39:44
ThreadLoad가 기본 데이터 구조로 Map<Thread, Object>를 직접 사용하는 경우, 많은 수의 스레드가 ThreadLocal을 사용하면 먼저 Map 액세스 성능이 저하됩니다. 스레드 수명 주기에 따라 기본 Map도 저하됩니다. 엔터티를 자주 추가하고 삭제하면 성능 병목 현상이 쉽게 발생할 수 있습니다.