사람들이 왜 여전히 Java에서 기본 유형을 사용합니까?

Java 5부터는 기본 유형의 boxing / unboxing이있어서 등등 int으로 포장되었습니다 java.lang.Integer.

나는 (즉, 최근에 새로운 자바 프로젝트를 많이 볼 확실히 사용되는하지 (6) 경우, 적어도 버전 5의 JRE를 필요로) int보다는 java.lang.Integer그것이 후자를 사용하는 것이 훨씬 더 편리하지만 그것을 변환하는 몇 가지 헬퍼 메소드를 가지고로, 행 long값 등의 알.

왜 일부는 여전히 Java에서 기본 유형을 사용합니까? 실질적인 이점이 있습니까?

Joshua Bloch의 Effective Java , 항목 5 : "불필요한 오브젝트 작성을 피하십시오"에서 다음 코드 예제를 게시합니다.

public static void main(String[] args) {
    Long sum = 0L; // uses Long, not long
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

실행하는 데 43 초가 걸립니다. Long을 프리미티브로 가져 가면 6.8 초로 줄어 듭니다. 이것이 프리미티브를 사용하는 이유에 대한 증거라면.

고유 가치 평등의 부족 또한 우려됩니다 ( .equals()에 비해 상당히 장황합니다 ==)

biziclop의 경우 :

class Biziclop {

    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5));
        System.out.println(new Integer(500) == new Integer(500));

        System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
    }
}

결과 :

false
false
true
false

_^편집 왜 (3)이 반환 true되고 (4)가 반환 false됩니까?

그것들은 두 개의 다른 객체이기 때문입니다. 0에 가장 가까운 256 개의 정수 [-128; 127]는 JVM에 의해 캐시되므로 동일한 객체를 반환합니다. 그러나이 범위를 넘어 서면 캐시되지 않으므로 새 객체가 만들어집니다. 더 복잡하게하기 위해 JLS 는 최소 256 개의 플라이 웨이트를 캐시해야합니다. JVM 구현자는 원하는 경우 더 많은 것을 추가 할 수 있습니다. 즉, 가장 가까운 1024가 캐시되어 모두 true를 반환하는 시스템에서 실행될 수 있습니다 ... #awkward

자동 박스 해제로 인해 NPE를 찾기가 어려울 수 있습니다.

Integer in = null;
...
...
int i = in; // NPE at runtime

대부분의 경우 null 할당 in은 위의 것보다 훨씬 덜 명확합니다.

박스형은 성능이 떨어지고 더 많은 메모리가 필요합니다.

기본 유형 :

int x = 1000;
int y = 1000;

이제 평가하십시오 :

x == y

그것은이다 true. 놀랍지 않습니다. 이제 박스 타입을 사용해보십시오 :

Integer x = 1000;
Integer y = 1000;

이제 평가하십시오 :

x == y

그것은이다 false. 아마. 런타임에 따라 다릅니다. 그 이유는 충분합니까?

성능 및 메모리 문제 외에도 다른 문제 가 있습니다 . List인터페이스 가 없으면 인터페이스 가 손상되었습니다 int.
문제는 오버로드 된 remove()방법 ( remove(int)vs. remove(Object))입니다. remove(Integer)항상 후자를 호출하여 해결할 수 있으므로 색인으로 요소를 제거 할 수 없습니다.

반면에 int: 를 추가하고 제거하려고 할 때 함정이 있습니다 .

final int i = 42;
final List<Integer> list = new ArrayList<Integer>();
list.add(i); // add(Object)
list.remove(i); // remove(int) - Ouch!

당신은 정말 상상할 수 있습니까

  for (int i=0; i<10000; i++) {
      do something
  }

대신 java.lang.Integer로 루프? java.lang.Integer는 변경할 수 없으므로 루프마다 증가 할 때마다 단일 JVM 명령으로 스택에서 int를 증가시키는 대신 힙에 새로운 Java 객체를 작성합니다. 성능은 악마적일 것입니다.

나는 int보다 java.lang.Integer를 사용하는 것이 편리하다는 점에 동의하지 않습니다. 반대로. Autoboxing은 Integer를 사용해야하는 경우 int를 사용할 수 있으며 Java 컴파일러는 코드를 삽입하여 새 Integer 객체를 만듭니다. 오토 박싱은 컴파일러가 관련 객체 구성을 삽입하면서 Integer가 필요한 곳에서 int를 사용할 수있게하는 것입니다. 처음부터 int의 필요성을 제거하거나 줄이는 것은 아닙니다. 오토 박싱을 사용하면 두 세계를 모두 활용할 수 있습니다. 힙 기반 Java 객체가 필요할 때 자동으로 Integer가 생성되며 산술 및 로컬 계산을 수행 할 때 int의 속도와 효율성을 얻습니다.

기본 유형은 훨씬 빠릅니다.

int i;
i++;

정수 (모든 숫자 및 문자열)는 변경할 수없는 유형입니다. 일단 작성된 후에는 변경할 수 없습니다. iInteger 라면 i++새로운 Integer 객체를 생성하는 것 보다 메모리와 프로세서 측면에서 훨씬 비쌉니다.

가장 먼저 습관. 8 년 동안 Java로 코딩 한 경우 상당한 양의 관성이 누적됩니다. 그럴만한 이유가 없다면 왜 변화해야합니까? 박스형 프리미티브를 사용하는 것이 추가적인 이점을 제공하는 것과는 다릅니다.

다른 이유는 null이것이 유효한 옵션이 아니라고 주장하는 것 입니다. 두 숫자의 합 또는 루프 변수를로 선언하는 것은 의미가없고 오해의 소지가 있습니다 Integer.

성능 측면도 있지만 많은 경우 성능 차이가 중요하지 않지만 (아마도 나쁘지만) 우리가 이미 더 빠른 방법으로 쉽게 작성할 수있는 코드를 작성하는 사람은 아무도 없습니다. 사용.

그건 그렇고, 스몰 토크는 객체 (프리미티브가 없음) 만 가지고 있지만 힙 공간을 할당하지 않고 작은 비트 정수를 최적화하기 위해 (32 비트를 모두 사용하지 않고 27 등을 사용하여) 작은 정수를 최적화했지만 단순히 특수 비트 패턴을 사용합니다. 또한 다른 공통 객체 (true, false, null)에는 특별한 비트 패턴이 있습니다.

따라서 적어도 64 비트 JVM (64 비트 포인터 네임 스페이스 사용)에서는 정수, 문자, 바이트, 짧은, 부울, 부동 및 작은 Long의 객체를 전혀 가질 수 없습니다 (생성 된 것 외에도) 명시 적으로 new ...()), 특수 비트 패턴 만 정상 연산자가 매우 효율적으로 조작 할 수 있습니다.

나는 내가 가장 중요한 이유라고 생각하는 것을 언급 한 사람은 아무도 없다. "int"는 "정수"보다 입력하기가 훨씬 쉽다. 사람들이 간결한 구문의 중요성을 과소 평가한다고 생각합니다. 숫자를 사용하는 대부분의 시간이 루프 인덱스에 있기 때문에 성능을 실제로 피하는 이유는 아닙니다. int 또는 Integer를 사용하든간에 사소하지 않은 루프에서는 그 값을 늘리고 비교하는 데 아무런 비용이 들지 않습니다.

다른 주어진 이유는 NPE를 얻을 수 있었지만 박스 유형으로 피하는 것이 매우 쉽다는 것입니다 (그리고 항상 null이 아닌 값으로 초기화하는 한 피할 수 있습니다).

다른 이유는 (new Long (1000)) == (new Long (1000))이 false 였지만 ".equals"가 상자 유형에 대해 구문 지원을 제공하지 않는다는 또 다른 방법입니다 (<,> , = 등)이므로 "더 간단한 구문"이유로 돌아갑니다.

Steve Yegge의 비 기본 루프 예제는 내 요점을 잘 보여줍니다. http://sites.google.com/site/steveyegge2/language-trickery-and-ejb

이것을 생각해보십시오 : Runnable 및 Callable과 같은 인터페이스를 사용하여 시뮬레이션 해야하는 Java와 비교하여 구문이 좋은 언어 (함수 언어, 파이썬, 루비 및 C와 같은)에서 함수 유형을 얼마나 자주 사용합니까? 이름없는 클래스.

프리미티브를 제거하지 않는 몇 가지 이유 :

• 역 호환성.

제거되면 이전 프로그램은 실행되지 않습니다.

• JVM 재 작성

이 새로운 것을 지원하기 위해 전체 JVM을 다시 작성해야합니다.

• 더 큰 메모리 공간.

더 많은 메모리를 사용하는 값과 참조를 저장해야합니다. 바이트 배열 byte이 큰 경우의를 사용하는 것이를 사용하는 것보다 훨씬 작습니다 Byte.

• 널 포인터 문제

선언 int i한 다음 작업을 수행 i하면 문제가 발생하지 않지만 선언 Integer i하고 동일한 작업을 수행하면 NPE가 발생합니다.

• 평등 문제.

이 코드를 고려하십시오.

Integer i1 = 5;
Integer i2 = 5;

i1 == i2; // Currently would be false.

거짓 일 것이다. 연산자는 과부하가되어야하며, 그로 인해 큰 재 작성이 발생합니다.

• 느린

오브젝트 랩퍼는 해당 원시 랩퍼보다 상당히 느립니다.

객체는 기본 유형보다 훨씬 무거 우므로 기본 유형이 랩퍼 클래스 인스턴스보다 훨씬 효율적입니다.

기본 유형은 매우 간단합니다. 예를 들어 int는 32 비트이고 메모리에서 정확히 32 비트를 차지하며 직접 조작 할 수 있습니다. Integer 객체는 완전한 객체로, 모든 객체와 마찬가지로 힙에 저장되어야하며 참조 (포인터)를 통해서만 액세스 할 수 있습니다. 또한 32 비트 (4 바이트) 이상의 메모리를 차지합니다.

즉, 자바가 프리미티브 유형과 비 프리미티브 유형을 구분한다는 사실은 Java 프로그래밍 언어의 시대를 나타내는 신호이기도합니다. 최신 프로그래밍 언어에는 이러한 차이점이 없습니다. 그러한 언어의 컴파일러는 간단한 값이나 더 복잡한 객체를 사용하는 경우 스스로 알아낼 수있을만큼 똑똑합니다.

예를 들어, 스칼라에는 기본 유형이 없습니다. 정수에 대한 클래스 Int가 있으며 Int는 실제 객체입니다 (메서드 등을 사용할 수 있음). 컴파일러가 코드를 컴파일 할 때 씬 뒤에서 기본 정수를 사용하므로 Int를 사용하는 것이 Java에서 기본 int를 사용하는 것만 큼 효율적입니다.

다른 사람들이 말한 것 외에도 원시 로컬 변수는 힙에서 할당되지 않고 스택에서 할당됩니다. 그러나 객체는 힙에서 할당되므로 가비지 수집해야합니다.

기본 유형에는 많은 장점이 있습니다.

• 간단한 코드 작성
• 변수의 객체를 인스턴스화하지 않기 때문에 성능이 향상됩니다.
• 그것들은 객체에 대한 참조를 나타내지 않기 때문에 null을 확인할 필요가 없습니다.
• 복싱 기능을 이용할 필요가 없으면 기본 유형을 사용하십시오.

어떤 종류의 최적화가 적용되는지 알기가 어렵습니다.

로컬 사용의 경우 컴파일러에 null 값 가능성을 제외하고 최적화를 수행하기에 충분한 정보가 있으면 성능이 같거나 비슷할 것으로 기대합니다 .

그러나 프리미티브 배열 은 박스형 프리미티브 컬렉션과 매우 다릅니다 . 컬렉션 내에서 깊이 최적화가 거의 불가능하다는 점을 감안하면 이치에 맞습니다.

또한 다음 과 비교할 때 논리적 오버 헤드Integer 가 훨씬 높습니다 . 이제 예외를 throw 할지 여부에 대해 걱정해야합니다 .intint a = b + c;

필자는 프리미티브를 최대한 많이 사용하고 팩토리 메소드와 오토 박싱에 의존하여 필요할 때 더 의미 론적으로 강력한 박스 유형을 제공합니다.

int loops = 100000000;

long start = System.currentTimeMillis();
for (Long l = new Long(0); l<loops;l++) {
    //System.out.println("Long: "+l);
}
System.out.println("Milliseconds taken to loop '"+loops+"' times around Long: "+ (System.currentTimeMillis()- start));

start = System.currentTimeMillis();
for (long l = 0; l<loops;l++) {
    //System.out.println("long: "+l);
}
System.out.println("Milliseconds taken to loop '"+loops+"' times around long: "+ (System.currentTimeMillis()- start));

Long 주위에서 '100000000'회 반복하는 데 걸린 시간 (밀리 초) : 468

긴 시간 동안 '100000000'회 반복하는 데 걸린 시간 (밀리 초) : 31

참고로, 이와 같은 것이 Java로 들어가는 것을 보지 않아도됩니다.

Integer loop1 = new Integer(0);
for (loop1.lessThan(1000)) {
   ...
}

for 루프가 loop1을 0에서 1000으로 자동 증가시키는 경우 또는

Integer loop1 = new Integer(1000);
for (loop1.greaterThan(0)) {
   ...
}

for 루프는 loop1 1000을 0으로 자동 감소시킵니다.

1. 수학 연산을 수행하려면 프리미티브가 필요합니다.
2. 프리미티브는 위에서 언급 한 메모리 사용량을 줄이고 성능을 향상시킵니다.

클래스 / 객체 유형이 필요한 이유를 물어야합니다

개체 유형을 갖는 이유는 컬렉션을 다룰 때 삶을 더 쉽게 만들기 위해서입니다. 기본 요소는 목록 / 맵에 직접 추가 할 수 없으며 랩퍼 클래스를 작성해야합니다. Readymade Integer 종류의 클래스는 여기에 도움이되며 Integer.pareseInt (str)와 같은 많은 유틸리티 메소드가 있습니다.

프리미티브 래퍼 객체를 사용하면 비용이 많이들 수 있습니다. 그러나 응용 프로그램에서 성능이 중요하지 않은 경우 개체를 사용할 때 오버플로를 피할 수 있습니다. 예를 들면 다음과 같습니다.

long bigNumber = Integer.MAX_VALUE + 2;

값 bigNumber은 -2147483647이며 값 은 2147483649 일 것으로 예상됩니다. 코드의 버그는 다음을 수행하여 수정됩니다.

long bigNumber = Integer.MAX_VALUE + 2l; // note that '2' is a long now (it is '2L').

그리고 bigNumber때때로 놓칠 수 쉽게 알 수없는 행동이나 취약점으로 이어질 수 버그 이러한 종류의 2147483649. 될 것이다 (참조 CWE-190 ).

래퍼 객체를 사용하면 동등한 코드가 컴파일되지 않습니다.

Long bigNumber = Integer.MAX_VALUE + 2; // Not compiling

따라서 프리미티브 래퍼 객체를 사용하면 이러한 종류의 문제를 더 쉽게 막을 수 있습니다.

귀하의 질문에 이미 답변되어 있으므로 이전에 언급되지 않은 정보를 조금 더 추가하기 위해 회신합니다.

JAVA는 모든 수학적 연산을 기본 유형으로 수행하기 때문입니다. 이 예제를 고려하십시오.

public static int sumEven(List<Integer> li) {
    int sum = 0;
    for (Integer i: li)
        if (i % 2 == 0)
            sum += i;
        return sum;
}

여기서 미리 알림 및 단항 더하기 연산은 Integer (Reference) 유형에 적용 할 수 없으며 컴파일러는 개봉을 수행하고 작업을 수행합니다.

따라서 자바 프로그램에서 얼마나 많은 오토 박스 및 언 박스 작업이 발생하는지 확인하십시오. 이 작업을 수행하는 데 시간이 걸립니다.

일반적으로 참조 유형의 인수와 기본 유형의 결과를 유지하는 것이 좋습니다.

기본 유형이 있습니다 훨씬 더 빨리 그리고 더 필요 적은 메모리를 . 따라서 우리는 그것들을 사용하는 것을 선호 할 수 있습니다.

반면, 현재 Java 언어 사양에서는 Java 컬렉션 또는 Reflection API에서 매개 변수화 된 형식 (일반)의 기본 형식을 사용할 수 없습니다.

응용 프로그램에 많은 수의 요소가 포함 된 컬렉션이 필요한 경우 가능한 한 "경제적 인"유형의 배열을 사용해야합니다.

* 자세한 내용은 https://www.baeldung.com/java-primitives-vs-objects를 참조하십시오.

간단히 말해서 : 기본 유형은 박스 유형보다 빠르며 더 적은 메모리를 필요로합니다.