[Java] 자바 메모리 구조, String vs StringBuilder vs StringBuffer, 메모리 주소(힙 메모리 누수 팁), GC(가비지 컬렉터)

 

출처 : https://coding-factory.tistory.com/830

 

메소드(Method) 영역

Static 영역이라고도 하며 전역 변수와 정적 멤버변수(static 변수)가 저장되는 영역입니다.

공통으로 사용 가능한 영역이라 Static 영역에는 다 같이 쓰이는 객체를 선언하면 좋습니다.

Static 영역의 데이터는 프로그램의 시작부터 종료가 될 때까지 메모리에 남아있게 됩니다.

예) 사용자 50명이 주소검색 API를 요청할 때 주소API코드 = “000000001“ 공통적인 부분이 쓰일 경우 50명의 객체를 만들어서 힙 메모리에 쌓이게 하는 방법보다는 공통적으로 다 사용하는 메소드 영역에 선언하는게 더 효율적이다.

 

스택(Stack) 영역

지역변수, 인자값, 리턴값이 저장되는 영역이고 메소드 안에서 사용되는 기본형 변수들이 값과 함께 저장되고 Heap 영역에 생성된 객체들을 참조하는 주소값이 할당됩니다.

예) String name = “Annna” 일 경우 name 이라는 변수가 힙 영역에 생성된 Annna라는 값을 참조하게 됩니다.

 

 

힙(Heap) 영역

자바 프로그램에서 사용되는 모든 인스턴스 변수(객체)들이 저장되는 영역입니다.

힙 영역은 메모리 공간이 동적으로 할당되고 해제되며 메모리의 낮은 주소에서부터 높은 주소로 할당이 이루어집니다

예) Annna라는 값은 여기에 생성되게 됩니다.

 

출처 : https://pjh3749.tistory.com/255

 

String 은 매우 자주 쓰이게 때문에 특별 대우를 받습니다.

String의 특징으로는 불변의 값을 넣는게 좋습니다.

문자열 리터럴은 공통 풀(공통 영역)에 공유 데이터로 저장 되기 때문에 불변의 값을 넣도록 설계 되어 있습니다.

 

String s1 = "Hello"; // String literal

String s2 = "Hello"; // String literal

String s3 = s1; // 같은 참조

String s4 = new String("Hello"); // String object (객체)

String s5 = new String("Hello"); // String object (객체)

 

s1, s2, s3의 경우 Hello라는 공통의 값을 참조하기 때문에 메모리 효율성이 좋습니다. (공통 풀에 저장된 값을 참조)

반면 s4, s5와 같이 new로 생성한 경우 Heap 영역에 따로 따로 생성되기 때문에 메모리 관리에 비효율적입니다.

 

만약 String이 계속 수정 되어야 한다면 StringBuffer나 StringBuilder를 사용하세요

 

StringBuffer와 StringBuilder의 결과는 동일하지만 상황에 따라 쓰이는게 약간 다릅니다.

StringBuffer의 경우는 멀티스레드의 환경에서 안전하게 돌아가도록 만든 것이고

StringBuilder의 경우 싱글스레드의 환경에서 안전하게 돌아가도록 만든 것입니다.

 

 

결과적으로 String 객체들의 연산이 이루어지면, 새로운 객체를 계속 만들어내기 때문에 메모리 관리 측면에서 상당히 비효율적이다.
이러한 이유로 만들어진 메모리영역이 Heap 안에 있는 String Constant Pool이다. 

여기에는 기존에 만들어진 문자열 값이 저장되어 있고, s1과 s2처럼 리터럴로 생성된 같은 값을 가지는 객체는 같은 레퍼런스를 가지게 됩니다.

 

출처: https://ict-nroo.tistory.com/18 [개발자의 기록습관:티스토리]

 

메모리 주소 값 확인하는 법

<dependency> 
    <groupId>org.openjdk.jol</groupId> 
    <artifactId>jol-core</artifactId>    
    <version>0.10</version> 
</dependency>

System.out.println("Memory address: " + VM.current().addressOf(obj));

HashCode의 값과 addressOf의 값은 다르다

(글을 찾아보면 HashCode값이 주소값이라고 하지만 정확히 상기 라이브러리를 사용해 addressOf 메소드를 사용할 시 정확하게 나온다.)

 

String hashCodeStr1 = "abcde";
String hashCodeStr2 = new String("abcde");

long hashCode1 = hashCodeStr1.hashCode(); 
long hashCode2 = hashCodeStr2.hashCode(); 

System.out.println("hashCode1 : " + hashCode1); // hashCode1 : 92599395
System.out.println("hashCode2 : " + hashCode2); // hashCode2 : 92599395	
System.out.println(hashCodeStr1 ==  hashCodeStr2 ? "hashCodeStr1 == hashCodeStr2" : "hashCodeStr1 != hashCodeStr2");
// hashCodeStr1 != hashCodeStr2

hashCode의 값은 같지만 == 로 비교한 결과 다르다고 나온다.

 

참고로 == 의 경우 주소값을 비교하고 equals의 경우 해당 객체의 값을 비교합니다.

 

참고로 com.foo.Person@2f92e0f4 이렇게 객체값을 나오는 경우의 아래처럼 해석하시면 됩니다.

com.foo.MyType - 클래스의 이름. 즉, com.foo. 패키지의 MyType 클래스

@ - 문자열 구분자

2f92e0f4 - 객체의 hashcode

 

hashCode에 대한 참고 사이트 : https://brunch.co.kr/@mystoryg/132

hashCode에 대한 참고 사이트 : https://brunch.co.kr/@mystoryg/133

 

 

 

 

 

메모리릭이란

ld 영역에 계속 누적된 객체로 인해 Major GC가 빈번하게 발생하게 되면서,
프로그램 응답속도가 늦어지면서 성능 저하를 불러온다. 이는 결국 OutOfMemory Error로 프로그램이 종료
쓴 객체에 대한 참조를 해제하지 않으면 가비지 컬렉션의 대상이 되지 않아 계속 메모리가 할당 되는 메모리 누수 현상이 발생

 

 

메모리 누수 팁

일단 정확히 어디에서 메모리가 누수되는지는 각자가 코딩한 코드내용에 따라 다 다르기 때문에 한정짓기는 힘들지만 개발할 때 지양해야할 사항 및 지향해야할 사항 및 알아두면 좋은 내용으로 구성했습니다.

 

정확한 원인 파악은 메모리 덤프 후 메모리 덤프를 분석해야 합니다.

 

기본적으로 Stack에서 Heap에 있는 객체를 참조하고 있는 동안에는 해당 객체는 GC에 의해 소멸되지 않습니다. 그에 대한 해결 방안입니다.

 

1. 불변의 값인 경우 String을 선언하고 값이 변동하는 경우 StringBuilder나 StringBuffer를 사용한다.

2. Http 객체 및 DB Connection 등... 사용 후 close()를 잘 해준다.

3. 모두 공유하는 값이 있고 불변의 경우 static final로 static에 선언해준다.

4. 다 쓴 객체에 Null을 할당한다.

 

참고로 XML과 JSON 파싱은 메모리를 가장 많이 사용합니다.

 

제가 봤을 때 가장 중요한건 4번입니다.

웬만한 객체들은 JVM에서 GC를 해주기 때문에 문제가 없지만 메소드를 호출하며 객체 잔뜩 만들고 그 이후에 사용 안 되는 경우 및 엄청난  사용자가 이용할 경우 복합적인 이유로 인해 참조가 남아서 GC 대상에서 제외되어서 OOM(Out of Memory)가 나게 됩니다. 

물론 코딩하면서 메모리 구조가 어떻게 만들어지고 다 머리에 그려지고 GC타이밍 등 다 파악 해 코딩하는 경우 필요한 부분만 null 사용하면 됩니다.

 

 

 

참고로 2번도 close() 메소드 내용 까보면 null을 할당해주는 짓을 하고 있습니다.

private final static int ALLOC_SIZE = (int) (Runtime.getRuntime().maxMemory() * 0.60);

public void allocate() {

    System.out.println("Before first allocation");
    byte[] b = new byte[ALLOC_SIZE];
    System.out.println("After first allocation");

    System.out.println("Before second allocation");
    byte[] b2 = new byte[ALLOC_SIZE];
    System.out.println("After second allocation");

}

public static void main(String[] args) {
    new GCTest().allocate();
}

Null 처리를 안 한 경우

 

재할당이 안 됩니다.

 

private final static int ALLOC_SIZE = (int) (Runtime.getRuntime().maxMemory() * 0.60);

public void allocate() {

    System.out.println("Before first allocation");
    byte[] b = new byte[ALLOC_SIZE];
    System.out.println("After first allocation");
    b = null;
    System.out.println("After assign null to b");
    System.out.println("Before second allocation");
    byte[] b2 = new byte[ALLOC_SIZE];
    System.out.println("After second allocation");
}

public static void main(String[] args) {
    new allocate();
}

Null 처리를 한 경우

 

재할당이 가능해집니다.

 

 

참고로 배열의 경우 모든 인덱스의 null을 넣어줘야 합니다.

 

이렇게 함으로써 얻을 수 있는 부가적인 장점은 누군가가 악의적으로 혹은 실수로 해당 객체를 다시 사용하려 했을 때 NullPointException이 발생하며 사전에 에러를 발생시킬 수 있다는 점이 있습니다만 단점으로는 코드가 지저분하게 됩니다.

 

이러한 방법을 깔끔하게 해결할 수 있는 객체들이 나오기 시작했는데요 WeakHashMap 등이 있습니다.

 

 

출처 : https://js2prince.tistory.com/entry/Java-%EA%B0%9D%EC%B2%B4-%EC%82%AC%EC%9A%A9%ED%9B%84-null-%ED%95%A0%EB%8B%B9-%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98-%EB%A7%90%EC%95%84%EC%95%BC-%ED%95%98%EB%82%98

 

 

GC 구조

 

GC 일반적 동작순서

 

 

Mark And Sweep Sometimes Compact
Mark - 참조 객체 파악
Sweep - 참조 안 하는 객체 삭제
Compact - Sweep하면서 비어있는 메모리의 단편화를 막기 위해 응집시키는 역할 (때때로 발생)

 

 

WAS(톰캣)을 사용해 구동시킬 때 메모리 크기를 정할 수 있다.

메모리크기가 큰 경우
  1. GC 발생횟수는줄어든다.
  2. GC 수행시간은길어진다.

메모리크기가 작은 경우
  1. GC 수행시간은적어진다.
  2. GC 발생횟수는증가한다.

 

메모리 크기에 따라 일장일단이 있어 잘 설정해야합니다.

크기를 무제한으로 두는 경우 서버의 메모리를 다 차지해 서버가 뻗는 경우도 존재하지만 이미 WAS가 뻗어버리면

서비스가 안 되므로 그거나 그거나 인 거 같습니다.

 

GC 종류

 

Minor GC

Young 영역에서 발생하는 GC

 

Major GC

Old 영역에서 발생하는 GC

 

Full GC

Young과 Old영역에 생성된 객체를 모두 지웁니다.

Full GC는 속도가 매우 느리고, Full GC가 발생하는 순간, 자바 어플리케이션이 멈춥니다. 
따라서 Full GC는 성능과 안정성에 아주 큰 영향을 미칩니다.

Old 영역으로 이동하는 객체의 수를 줄이면 Full GC가 발생하는 빈도를 많이 줄일 수 있습니다.
최대한 FULL GC는 나오면 안 되며 웬만해서 Minor GC에서 다 처리하도록 해야합니다.

그렇다고 Full GC 실행 시간을 줄이기 위해서 Old 영역의 크기를 줄이면 자칫 OutOfMemoryError가 발생하거나 Full GC 횟수가 늘어난다. 
반대로 Old 영역의 크기를 늘리면 Full GC 횟수는 줄어들지만 실행 시간이 늘어난다. Old 영역의 크기를 적절하게 잘 설정해야 한다.

FULL GC에는 다양한 FULL GC가 존재한다. (Parallel GC Concurrent GC Train GC....등)

 

 

JAVA7까지는 PERM 영역이 존재하는데 이는 영구적일 것이라고 생각하는 객체들을 관리합니다.

이 영역은 GC 대상에서 제외됩니다. 하지만 이 때문에 GC가 안 되어 OOM이 발생해 뻗어버리는 경우가 발생합니다.

 

최근 Java 8에서는 JVM 메모리 구조적인 개선 사항으로 Perm 영역이 Metaspace 영역으로 전환되고 기존 Perm 영역은 사라지게 되었다.  
Metaspace 영역은 Heap이 아닌 Native 메모리 영역(서버 메모리)으로 취급하게 된다. 

(Heap 영역은 JVM에 의해 관리된 영역이며, Native 메모리는 OS 레벨에서 관리하는 영역으로 구분된다) 

Metaspace가 Native 메모리를 이용함으로서 개발자는 영역 확보의 상한을 크게 의식할 필요가 없어지게 되었다.)
즉 개발자는 이 영역에 대해서 신경쓰지 않아도 JVM이 알아서 늘려주는 역할을 해줍니다.

 

 

출처 : https://www.youtube.com/watch?v=Fe3TVCEJhzo&t=260s