Java Language
Java 성능 튜닝
수색…
일반적인 접근
인터넷에는 Java 프로그램의 성능 향상을위한 팁이 있습니다. 아마도 최고의 팁은 인식입니다. 그 의미는:
- 가능한 성능 문제 및 병목 현상을 식별하십시오.
- 분석 및 테스트 도구를 사용하십시오.
- 좋은 습관과 나쁜 습관을 아십시오.
새로운 시스템이나 모듈에 대해 말하면 디자인 단계에서 첫 번째 사항을 수행해야합니다. 레거시 코드에 대해 말하면 분석 도구와 테스트 도구가 등장합니다. JVM 성능 분석을위한 가장 기본적인 도구는 JVisualVM이며 JDK에 포함되어 있습니다.
세 번째 포인트는 주로 경험과 광범위한 연구에 대해, 그리고 물론 원시 팁의이 페이지 및 비슷한 페이지에 표시됩니다 그 이 .
문자열 줄이기
Java에서는 필요하지 않은 많은 String 인스턴스를 만드는 것이 너무 쉽습니다. 그와 다른 이유로 인해 프로그램에서 GC가 정리 작업 중 인 많은 String을 가질 수 있습니다.
String 인스턴스를 작성하는 몇 가지 방법은 다음과 같습니다.
myString += "foo";
루프 또는 재귀에서
for (int i = 0; i < N; i++) {
myString += "foo" + i;
}
문제는 각 +
가 새로운 String을 생성한다는 것입니다 (일반적으로 새로운 컴파일러는 어떤 경우를 최적화하기 때문에). StringBuilder
또는 StringBuffer
사용하여 최적화 할 수 있습니다.
StringBuffer sb = new StringBuffer(myString);
for (int i = 0; i < N; i++) {
sb.append("foo").append(i);
}
myString = sb.toString();
긴 문자열을 자주 작성하는 경우 (예 : SQL) String 작성 API를 사용하십시오.
고려해야 할 기타 사항 :
-
replace
,substring
등의 사용을 줄입니다. - 특히 자주 액세스되는 코드에서는
String.toArray()
피하십시오. - 필터링 할 예정인 로그 인쇄 (예 : 로그 레벨로 인해)가 생성되어서는 안됩니다 (로그 레벨은 사전에 확인해야합니다).
- 필요한 경우이 라이브러리를 사용하십시오.
- 변수가 비공유 방식 (스레드 간)으로 사용되는 경우 StringBuilder가 더 좋습니다.
Java 성능 튜닝에 대한 증거 기반 접근 방식
Donald Knuth는 다음과 같이 종종 인용합니다.
"프로그래머는 시간의 엄청난 양의 생각, 또는 프로그램의 중요하지 않은 부분의 속도에 대한 걱정, 디버깅 및 유지 보수. 우리는 작은 효율성에 대해 잊지한다 고려하면 효율성에서 이러한 시도가 실제로 강한 부정적인 영향을 미칠 낭비에 대한 말 시간의 97 % : 조숙 한 최적화가 모든 악의 뿌리입니다. 그러나 우리는 그 3 %에서 기회를 포기해서는 안됩니다. "
sage 조언을 염두에두고 다음과 같이 프로그램을 최적화하는 것이 좋습니다.
우선, 단순성과 정확성에 중점을두고 프로그램이나 라이브러리를 디자인하고 코딩하십시오. 먼저 성과에 많은 노력을 기울이지 마십시오.
그것을 작동 상태로 만들고 (이상적으로) 코드베이스의 핵심 부분에 대한 단위 테스트를 개발하십시오.
응용 프로그램 수준 성능 벤치 마크를 개발하십시오. 벤치 마크는 애플리케이션의 성능 측면을 포괄해야하며, 애플리케이션을 프로덕션 환경에서 사용하는 방법과 관련된 다양한 작업을 수행해야합니다.
성능을 측정하십시오.
측정 된 성능을 응용 프로그램의 속도에 대한 기준과 비교하십시오. ( "가능한 한 빨리"와 같이 비현실적이거나 달성 할 수 없거나 식별 할 수없는 기준을 피하십시오.)
기준을 충족했다면 중지하십시오. 너 일 끝났어. (더 이상의 노력은 아마도 시간 낭비 일 것입니다.)
성능 벤치 마크가 실행되는 동안 응용 프로그램의 프로필을 작성하십시오.
프로파일 링 결과를 검사하고 가장 큰 (최적화되지 않은) "성능 핫스팟"을 선택하십시오. 즉 응용 프로그램이 가장 많은 시간을 보내는 것처럼 보이는 부분의 코드입니다.
핫스팟 코드 섹션을 분석하여 병목 현상의 원인을 이해하고 속도를 높이는 방법을 생각하십시오.
이를 제안 된 코드 변경, 테스트 및 디버그로 구현하십시오.
코드 변경으로 인해 성능이 향상되었는지 벤치 마크를 재실행하십시오.
- 예이면 4 단계로 돌아가십시오.
- 아니요 인 경우 변경 사항을 취소하고 9 단계로 돌아가십시오. 진행하지 않을 경우 다른 핫스팟을 선택하십시오.
결국 응용 프로그램이 충분히 빠르거나 중요한 모든 핫스팟을 고려한 지점에 도달하게됩니다. 이 시점에서이 접근법을 중단해야합니다. 코드 섹션이 전체 시간의 1 %를 소비하는 경우, 50 % 향상만으로도 응용 프로그램이 전반적으로 0.5 % 더 빠릅니다.
분명히 핫스팟 최적화가 노력의 낭비를 넘어서는 지점이 있습니다. 이 점에 도달하면보다 급진적 인 접근이 필요합니다. 예 :
- 핵심 알고리즘의 알고리즘 복잡성을 살펴보십시오.
- 응용 프로그램에서 가비지 수집에 많은 시간을 소비하는 경우 개체 생성 속도를 줄이는 방법을 찾아보십시오.
- 응용 프로그램의 핵심 부분이 CPU 집중 형 및 단일 스레드 인 경우 병렬 처리를위한 기회를 찾으십시오.
- 응용 프로그램이 이미 멀티 스레드 인 경우 병목 현상 병목 현상을 찾으십시오.
그러나 가능한 한 어디서나 최적화 노력을 지시하기보다는 도구와 측정에 의존하십시오.