Java에서 -128에서 127 사이의 Integer를 정의 할 때 새 개체를 만드는 대신 이미 만든 개체를 반환하는 모든 곳을 읽었습니다.
초보자 프로그래머가 Integer 객체를 비교 ==하여 같은 수인지 확인하는 것 외에는이 작업을 수행 할 필요가 없지만 Integer와 어떤 Integer를 비교할 수 있다고 생각하고 ==가르치고 있기 때문에 이것이 나쁘다고 생각합니다. 모든 프로그래밍 언어에서 나쁜 습관 : 두 개의 '다른'객체의 내용을 ==.
이것이 수행되는 다른 이유가 있습니까? 아니면 JavaScript의 선택적 세미콜론과 같이 언어를 디자인 할 때 (제 관점에서) 잘못된 결정입니까?
편집 : 여기에서 그들이 동작을 설명하는 것을 볼 수 있습니다 . 정수 상수 풀의 동작이 127에서 변경되는 이유는 무엇입니까?
나는 그들이 왜 이런 행동을하도록 설계했는지 묻고 있는데 왜 이런 행동이 일어나는지가 아닙니다.
Flyweight 패턴 이라고 하며 메모리 사용량을 최소화하는 데 사용됩니다.
이러한 숫자는 반복적으로 사용될 가능성이 매우 높으며, 같은 자동 상자 유형 Integer은 변경할 수 없습니다 (에서만 수행되는 것이 아닙니다 Integer). 캐싱하면 인스턴스가 많지 않고 GC (Garbage Collection) 작업도 줄어 듭니다.
JLS는 5.1.7 에서이를 다룹니다 . 구체적으로 말해서 권투 변환 :
boxing되는 값 p가 true, false, 바이트 또는 \ u0000에서 \ u007f 범위의 char이거나 -128에서 127 (포함) 사이의 int 또는 짧은 숫자 인 경우 r1 및 r2는 p의 두 권투 변환. 항상 r1 == r2 인 경우입니다.
이상적으로 주어진 프리미티브 값 p를 박싱하면 항상 동일한 참조가 생성됩니다. 실제로 이것은 기존 구현 기술을 사용하여 실현 가능하지 않을 수 있습니다. 위의 규칙은 실용적인 타협입니다. 위의 마지막 절에서는 특정 공통 값을 항상 구별 할 수없는 개체로 묶어야합니다. 구현은 이러한 것들을 느리게 또는 열심히 캐시 할 수 있습니다. 다른 값의 경우,이 공식은 프로그래머 측에서 박스형 값의 식별에 대한 어떠한 가정도 허용하지 않습니다. 이렇게하면 이러한 참조의 일부 또는 전체를 공유 할 수 있습니다 (필수는 아님).
이렇게하면 특히 작은 장치에서 과도한 성능 저하없이 대부분의 일반적인 경우 동작이 원하는 동작이됩니다. 예를 들어 메모리 제한이 적은 구현은 모든 char 및 short 값은 물론 -32K에서 + 32K 범위의 int 및 long 값을 캐시 할 수 있습니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다