programing

Java Collections에서 Primitive 유형을 직접 저장할 수 없는 이유는 무엇입니까?

yoursource 2022. 12. 1. 23:50
반응형

Java Collections에서 Primitive 유형을 직접 저장할 수 없는 이유는 무엇입니까?

Java 컬렉션에는 오브젝트만 저장되며 기본 유형은 저장되지 않지만 래퍼 클래스는 저장할 수 있습니다.

왜 이런 제약일까요?

이는 Java의 설계 결정으로 일부에서는 오류로 간주됩니다.컨테이너에서 개체와 원시 요소가 개체에서 파생되지 않아야 합니다.

이곳은 의 한 장소입니다.NET 설계자는 JVM에서 배운 지식을 바탕으로 가치 유형 및 일반 기능을 구현하여 대부분의 경우 복싱이 필요하지 않습니다.CLR에서 일반 컨테이너는 기본 컨테이너 구조의 일부로 값 유형을 저장할 수 있습니다.

Java는 JVM의 지원 없이 컴파일러에 일반 지원을 100% 추가하기로 선택했습니다.JVM은 "개체가 아닌" 개체를 지원하지 않습니다.Java 제네릭스는 포장지가 없는 것처럼 꾸밀 수 있지만, 여전히 박스의 성능 대가를 지불합니다.이것은 특정 클래스의 프로그램에서 중요합니다.

복싱은 기술적인 타협이며, 구현의 세부 사항이 언어로 새어나간다고 생각합니다.오토박스는 통사적으로 좋은 설탕이지만, 여전히 퍼포먼스 패널티입니다.오히려 컴파일러가 자동박스를 할 때 경고해 주셨으면 합니다.(아마도 지금은 2010년에 이 답을 썼을 것입니다.)

권투에 대한 SO에 대한 좋은 설명:왜 일부 언어에는 Boxing과 Unboxing이 필요한가?

자바 제네릭스에 대한 비판:왜 Java의 제네릭 구현이 나쁘다고 주장하는가?

자바의 변호를 하자면, 과거를 돌아보고 비판하는 것은 쉽다.JVM은 오랜 세월의 테스트를 견뎌냈으며, 여러 면에서 훌륭한 설계입니다.

구현이 쉬워집니다.Java 프리미티브는 개체로 간주되지 않으므로 이러한 프리미티브 각각에 대해 별도의 컬렉션 클래스를 만들어야 합니다(공유할 템플릿 코드 없음).

물론 GNU Trove, Apache Commons Primitives 또는 HPPC만 볼 수 있습니다.

정말로 큰 컬렉션을 가지고 있지 않는 한, 래퍼의 오버헤드는 사람들이 신경 쓸 만큼 중요하지 않습니다(또한 매우 큰 프리미티브 컬렉션을 가지고 있는 경우에는 특별한 데이터 구조를 사용하거나 구축하기 위해 노력을 기울이는 것이 좋습니다).

두 가지 사실을 조합한 것입니다.

  • 들어 Java는 참조타입이 아닙니다).int 아니다Object)
  • 는 참조 Java).List<?>이지 ★★★★★★★★★★★★★★」List<Object> 시로 설정)

이 두 가지가 모두 사실이기 때문에 범용 Java 컬렉션은 원시 유형을 직접 저장할 수 없습니다.편의상, 자동 박스가 도입되어 프리미티브 타입을 참조 타입으로 자동 박스가 가능합니다.그러나 이 컬렉션에는 여전히 개체 참조가 저장되어 있습니다.

피할 수 있었을까요?그럴지도 모르죠.

  • 、 、int는 입니다.Object을 사용법
  • 제네릭이 유형 삭제를 사용하지 않는 경우 유형 매개 변수에 원시 요소가 사용되었을 수 있습니다.

자동 박스와 자동 언박스의 개념이 있습니다.저장하려고 할 경우intin a a a a List<Integer>합니다.Integer.

그게 사실 제약은 아니죠?

프리미티브 값을 저장한 컬렉션을 작성할 경우 고려합니다.int, float 또는 char를 저장할 수 있는 컬렉션은 어떻게 작성하시겠습니까?대부분의 경우 여러 수집이 이루어지기 때문에 intlist나 charlist 등이 필요합니다.

컬렉션 클래스를 작성할 때 Java의 객체 지향 특성을 활용하면 임의의 객체를 저장할 수 있으므로 하나의 컬렉션 클래스만 필요합니다.이 아이디어, 다형성은 매우 강력하며 도서관 설계를 크게 단순화시킨다.

주된 이유는 자바 디자인 전략입니다.++ 1) 컬렉션은 조작에 오브젝트가 필요하며, 프리미티브는 오브젝트에서 파생되지 않기 때문에 다른 이유일 수 있습니다. 2) Java 프리미티브 데이터 타입은 예를 들어 참조 타입이 아닙니다.int는 오브젝트가 아닙니다.

극복 방법:-

우리는 자동 삭제와 자동 언박스의 개념을 가지고 있습니다.따라서 만약 당신이 원시 데이터 타입을 저장하려고 한다면 컴파일러는 그것을 그 원시 데이터 클래스의 객체로 자동 변환합니다.

이 JEP - http://openjdk.java.net/jeps/218를 기반으로 Java 10에서 JDK의 진척을 볼 수 있을 것 같습니다.

현재 컬렉션에서 프리미티브를 박스화하지 않으려면 몇 가지 서드파티를 선택할 수 있습니다.앞서 언급한 서드파티 옵션 외에 Eclipse Collections, Fast Util 및 Koloboke있습니다.

또한 얼마 전 "Large HashMap 개요: JDK, FastUtil, Goldman Sachs, HPPC, Koloboke, Trove"라는 제목과 함께 원시 지도의 비교가 발표되었습니다.GS Collections(Goldman Sachs) 라이브러리는 Eclipse Foundation으로 마이그레이션되어 현재는 Eclipse Collections입니다.

언급URL : https://stackoverflow.com/questions/2504959/why-can-java-collections-not-directly-store-primitives-types

반응형