BigDecimal compareTo() 스레드 안전성

BigDecimal 클래스의 compareTo() 메서드를 사용하는 Java 응용 프로그램에서 해당 유형 (기본적으로 "너무 큼")에 따라 문자열을 읽는 (큰) , double 또는 float). 응용 프로그램은 초당 매우 많은 수의 문자열을 읽으므로 성능 최적화가 필수적입니다.BigDecimal compareTo() 스레드 안전성

static final BigDecimal MAX_LONG = new BigDecimal(Long.MAX_VALUE); 
static final BigDecimal MAX_FLOAT = new BigDecimal(Float.MAX_VALUE); 
static final BigDecimal MAX_DOUBLE = new BigDecimal(Double.MAX_VALUE); 

String value = readValue(); // Read the number as a string 

BigDecimal number = new BigDecimal(value); 

if (number.compareTo(MAX_DOUBLE) > 0) 
{ 
    ... 
} 
else if (number.compareTo(MAX_FLOAT) > 0) 
{ 
    ... 
} 
else if (number.compareTo(MAX_LONG) > 0) 
{ 
    ... 
}

따라서, 다중 스레드 환경에서이 질문에

, 그것은 (정적 필드 주어진) 위의 비교를하는 것이 안전합니다 :

코드의 축약 발췌입니다 다음은?
위의 분류를 구현하는 스레드로부터 안전하고 빠른 방법이 있습니까?

출처

2012-10-29 PNS

* "성능 최적화가 필수적입니다."*이 특정 방법을 최적화해야한다는 결론에 어떻게 도달 했습니까? – NullUserException

나는 compareTo() 메서드가 아니라 내 코드를 참조하고 있었다. – PNS

질문은 의미합니다. 코드의 특정 부분을 최적화해야한다는 결론에 어떻게 도달 했습니까? – NullUserException

BigDecimal도 변경할 수 없으므로 스레드로부터 안전합니다.

가능할 수도있는 모든 캐싱을 활용하려면 전체적으로 new BigDecimal() 대신 BigDecimal.valueOf()을 사용해야합니다.

출처

2012-10-29 22:56:39 EJP

하지만'toString'는'BigDecimal'이 불변 일지라도 3 번 안전하지 않습니다. – Zarathustra

필자는 비교가 실제로 병목 현상인지 아닌지에 대한 질문에 동의합니다. 파일 또는 네트워크 IO 시간이 더 높습니다.

비교가 실제로 병목 현상이되어 데이터에 대한 IID 또는 유사한 가정을하면 각 간격에 해당하는 입력을 계산하는 히스토그램을 유지하고 테스트를 즉시 순서대로 정렬하면 비교 횟수가 줄어 듭니다. 가장 빈번한 사례가 먼저 확인됩니다.

예를 들어 MAX_DOUBLE보다 많은 숫자가있는 경우 현재 비교 사다리가 가장 좋습니다. 숫자 당 하나의 비교 만 필요합니다. 그러나 대부분의 숫자가 MAX_FLOAT보다 작거나 같은 경우 최악입니다. 숫자 당 세 번의 비교가 필요하기 때문입니다.

출처

2012-10-29 23:42:41 Gene

BigDecimal compareTo() 스레드 안전성

답변

관련 문제