내 컴퓨터에서 원래 버전은 32,000
ms는 1,000 만 번의 호출에 사용되며, 향상된 버전에는 130ms가 걸립니다.
약 250 배 빠릅니다. 성능이 향상되었을뿐만 아니라 선명도도 향상되었습니다.
붐 시작 및 붐 변경 로컬 변수에서 정적 최종 필드 만들기
이 날짜가 상수로 취급되어 코드가 더 이해할 수있게되었습니다.
전체 공개의 목적으로 이러한 종류의 최적화를 통해 절약 할 수 있습니다.
Calendar 인스턴스가 특히 비싸기 때문에 항상 극적인 것은 아닙니다
만들다.
Person 클래스의 개선 된 버전이 초기화되었지만 isBabyBoomer
메소드가 호출되지 않으면 BOOM_START 및 BOOM_END 필드가 초기화됩니다.
불필요하게. 불필요한 초기화를 제거하는 것이 가능할 것입니다.
isBabyBoomer 메서드가 처음으로이 필드를 지연 적으로 초기화 (Item 71)
호출되지만 권장되지는 않습니다. 게으른 초기화의 경우처럼 종종
구현을 복잡하게 만들 것이고 눈에 띄는 결과를 초래하지는 않을 것입니다
우리가 이미 달성 한 것 이상의 성과 개선 (항목 55).
이 항목의 이전 예제에서는 문제의 대상이
초기화 후에 수정되지 않았기 때문에 재사용 될 수 있습니다. 있다
그것이 덜 명백한 다른 상황. 어댑터의 경우를 생각해 보자. [감마 95,
피. 139], 뷰라고도합니다. 어댑터는 받침대에 위임 한 객체입니다.
객체로, 대체 객체에 대한 대체 인터페이스를 제공합니다. 어댑터
그것의 뒷받침 대상을 넘어선 상태가 없기 때문에 더 이상 생성 할 필요가 없습니다.
주어진 객체에 대한 주어진 어댑터의 하나의 인스턴스.
예를 들어, Map 인터페이스의 keySet 메소드는
지도의 모든 키로 구성된지도 개체입니다. 순진하게도,
keySet를 호출하면 새 Set 인스턴스를 만들어야하지만 keySet을 호출 할 때마다
지정된 Map 객체의 Set 객체가 동일한 Set 인스턴스를 반환 할 수 있습니다. 반환 된
Set 인스턴스는 일반적으로 변경 가능하며 반환 된 모든 객체는 기능상 동일합니다.
반환 된 객체 중 하나가 변경되면 다른 객체도 모두 변경됩니다.
그것들은 모두 같은 Map 인스턴스에 의해 뒷받침됩니다. 여러 번 만들면 무해한 반면
keySet 뷰 객체의 인스턴스 인 경우에도 필요하지 않습니다.
언제 참조를 없애야합니까? Stack 클래스의 어떤면
메모리 누수가 발생하기 쉬운가? 간단히 말해서, 자체 메모리를 관리합니다.
저장 영역 풀은 요소 배열의 요소 (오브젝트 참조
세포가 아니라 개체 자체). 활성 부분의 요소는
배열 (앞에서 정의한대로)이 할당되고 나머지 배열의 배열
비어 있는. 가비지 컬렉터는 이것을 알 수있는 방법이 없습니다. 가비지 컬렉터에게
elements 배열에있는 모든 객체 참조가 똑같이 유효합니다. 프로그래머 만
배열의 비활성 부분이 중요하지 않음을 알 수 있습니다. 프로그래머
수동으로 사실을 가비지 수집기에 효과적으로 전달합니다.
배열 요소가 비활성 부분에 속하자마자 널 요소를 null로 만듭니다.
일반적으로 클래스가 자체 메모리를 관리 할 때마다 프로그래머
메모리 누출에주의해야합니다. 요소가 해제 될 때마다
요소에 포함 된 객체 참조를 제거해야합니다.
또 다른 메모리 누출 원인은 캐시입니다. 일단 당신이
객체 참조를 캐시에 저장하면, 그 객체가 있음을 잊어 버리고
캐시가 오래 걸리면 이 문제에 대한 해결책은 여러 가지가 있습니다.
엔트리가 정확히 관련있는 캐시를 구현할만큼 운이 좋은 경우
캐시 외부의 키에 대한 참조가있는 한 캐시를 나타냅니다.
WeakHashMap로서; 항목은 쓸모 없게 된 후 자동으로 제거됩니다.
WeakHashMap은 원하는 캐시 수명
항목은 값이 아닌 키에 대한 외부 참조에 의해 결정됩니다.
일반적으로 캐시 항목의 유효 수명은 덜 잘 정의되어 있습니다.
시간이 지남에 따라 항목이 덜 가치있게됩니다. 이러한 상황에서 캐시
때때로 사용하지 않는 항목을 정화해야합니다. 이것은 될 수있다.
백그라운드 스레드 (아마 Timer 또는 ScheduledThreadPoolExecutor)에 의해 수행됩니다.
또는 캐시에 새 항목을 추가하는 부작용입니다. LinkedHashMap
클래스는 removeEldestEntry 메소드로 후자의 접근을 용이하게합니다. 에 대한
보다 정교한 캐시라면 java.lang.ref를 직접 사용해야 할 수도있다.
메모리 누수의 세 번째 공통 소스는 리스너와 다른 콜백입니다.
클라이언트가 콜백을 등록하지만 등록을 취소하지 않은 API를 구현하는 경우
명시 적으로, 당신이 어떤 조치를 취하지 않으면 그들은 누적 될 것입니다. 가장 좋은 방법은
콜백이 즉시 가비지 수집되도록 보장하는 것은 약한 참조 만 저장하는 것입니다.
예를 들어 WeakHashMap에 키로 만 저장하면됩니다.
메모리 누수가 일반적으로 분명한 실패로 나타나지 않기 때문에,
그들은 수년 동안 시스템에 남아있을 수 있습니다. 그들은 일반적으로 발견된다.
신중한 코드 검사 또는 디버깅 도구의 도움을 받아야합니다.
힙 프로파일 러라고도합니다. 따라서 문제를 예측하는 것을 배우는 것이 바람직합니다.
이런 일이 발생하기 전에 이런 일이 일어나지 않도록하십시오.
종결자는 예측할 수없고, 종종 위험하며 일반적으로 불필요합니다.
이들을 사용하면 엉뚱한 동작, 성능 저하 및 이식성 문제가 발생할 수 있습니다.
파이널 라이저는 몇 가지 유효한 용도가 있지만이 항목의 뒷부분에서 다루겠습니다.
어림짐작을 피하십시오.
C ++ 프로그래머는 파이널 라이저를 Java의 아날로그라고 생각하지 않도록주의해야합니다.
C ++ 소멸자. C ++에서 소멸자는 리소스를 회수하는 일반적인 방법입니다.
객체와 관련된 생성자와 필요한 객체. 자바에서는 쓰레기
수집기가있을 때 개체와 관련된 저장소를 회수합니다.
도달 할 수 없으므로 프로그래머가 특별한 노력을 기울이지 않아도됩니다. C ++
소멸자는 다른 비 메모리 자원을 재 확보하는데도 사용됩니다. Java에서, tryfinally
블록이 일반적으로이 목적으로 사용됩니다.
종료 자의 한 가지 결점은 그들이 처형 될 것이라는 보장이 없다는 것입니다
즉시 [JLS, 12.6]. 물체가 움직일 때까지 임의로 길어질 수 있습니다.
도달 할 수 없게되고 파이널 라이저가 실행되는 시간이됩니다. 이것은
당신은 finalizer에서 시간 결정적으로 아무것도하지 말아야합니다. 예를 들어,
중대한 오류로 인해 파일을 닫는 데 파이널 라이저를 사용하지 마십시오. 열린 파일 설명자가
제한된 자원. 실행시 JVM이 지루하기 때문에 많은 파일이 열려있는 경우
finalizers, 더 이상 파일을 열 수 없기 때문에 프로그램이 실패 할 수 있습니다.
파이널 라이저가 실행되는 즉시는 기본적으로
가비지 수집 알고리즘은 JVM 구현과 크게 다릅니다.
JVM 구현. 신속성에 의존하는 프로그램의 동작
파이널 라이저 실행의 결과도 마찬가지로 달라질 수 있습니다. 그러한 가능성이 전적으로 가능합니다.
프로그램은 테스트를 거친 JVM에서 완벽하게 실행되고 비참하게 실패합니다.
가장 중요한 고객이 선호하는 JVM에서
지각 최종화는 단지 이론적 인 문제가 아닙니다. 에 대한 종료 자 제공
클래스는 드문 경우이지만 인스턴스의 임의 재생을 임의로 지연 할 수 있습니다. 에이
동료가 신비하게 죽어가는 GUI 응용 프로그램을 디버깅했습니다.
OutOfMemoryError와 함께. 분석 결과, 사망 당시에
응용 프로그램은 기다리고있는 finalizer 큐에 수천 개의 그래픽 객체가 있습니다.
확정되고 재생된다. 불행히도, 파이널 라이저 스레드는
다른 응용 프로그램 스레드보다 우선 순위가 낮으므로 개체가 마무리되지 않았습니다.
그 비율로 최종 결정권을 갖게되었습니다. 언어 사양에 따라
어떤 thread가 파이널 라이저를 실행하는지에 대한 보장이 없기 때문에 이식성이 없다.
finalizers 사용을 자제하는 것 이외의 이런 종류의 문제를 방지하는 방법.