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