이펙티브 자바를 읽다가 약한참조에 대한 이야기가 나와서 포스팅한다.

참조에는 아래 4가지가 존재한다.

• Strong References (강한 참조)
• Soft References (소프트 참조)
• Weak References (약한 참조)
• Phantom References (팬텀 참조)

이 해당 참조 유형에 따라 GC 실행 대상여부, 시점이 달라진다.

강한참조

new 연산자를 사용하여 객체를 인스턴스화 하고 참조하는 방식.

참조가 해제되지 않으면 GC의 대상이 되지 않는다.

Test test = new Test();

해당 test라는 변수가 참조를 가지고 있다면 GC의 대상이 되지 않는다.

test = null이 되는 순간 GC의 대상이 된다.

소프트참조

대상 객체의 참조가 SoftReference만 있다면 GC의 대상이 된다.

단, JVM 메모리가 부족한 경우에만 Heap에서 제거된다.

메모리가 부족하지 않은경우에는 제거하지 않는다.

public static void main(String[] args) {
        String ss = "문자열";
        SoftReference<String> reference = new SoftReference<>(ss);

        // 이 시점에 GC의 실행 대상이 가능
        ss = null;

        System.gc();

        // JVM의 메모리가 부족하지 않아서 GC 실행 대상이 되지 않은 경우
        // 그대로 유지한다.
        ss = reference.get();
        System.out.println(ss);
}

약한참조

위에서 봤던 소프트참조와 비슷하게 

대상 객체의 참조가 WeakReference만 있다면 GC의 대상이 된다.

다른점은, 메모리가 부족한경우가 아니라 다음 GC가 일어나게 되면 바로 힙에서 제거된다.

public static void main(String[] args) {
        String ss = "문자열";
        WeakReference<String> reference = new WeakReference<>(ss);

        // 이 시점에 GC의 실행 대상이 가능
        ss = null;

        System.gc();

        // gc를 명시적으로 호출했지만 컬렉션이 동작하지 않을수도 있음
        // 그래도 무조건 동작한다고 가정
        ss = reference.get();

        // null 로 비어있게 된다.
        System.out.println(ss);
}

팬텀참조

생성시 ReferenceQueue가 필요하며, PhantomReference의 참조값을 수동으로 clear() 메서드를 실행해야 하고, PhantomReference.get() 메서드는 항상 null을 반환한다는 특징이 있다.

PhantomReference는 객체 내부의 참조를 null로 설정하지 않고 참조된 객체를 phantomly reachable 객체로 만든 이후에 ReferenceQueue에 enqueue 된다.

두가지에서 사용한다.

1. 자원 정리 (finalizer 보다는 조금 나은 방법) 그렇지만 try-with-resources를 사용하자.
2. 생성 비용이 비싼 객체가 언제 메모리에서 해제되는지 알 수 있음.

깃허브 바로가기

4장 클래스와 인터페이스

이펙티브 자바를 TDD, Clean Code 과정을 수강하면서 들으니 이해가 잘되면서 잘 읽힌다❗

클래스와 멤버의 접근 권한을 최소화

ㅋㅋㅋㅋㅋㅋㅋㅋ 어제 Clean Code 과정에서 뼈저리게 겪었다...

랜덤값 부터 시작해서 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 차이는 클래스 내부 데이터를 각각 다른 외부 컴포넌트로부터 얼마나 추상화 하였는가가 결정 짓는다.

잘 설계되었다면 구현부, API를 깔끔하게 분리할 수 있다.
MVC 패턴만 사용했어 분리하는게 조금 어려웠다. 그런데 진도 나가면서 점점 발전하는것 같다. 😁

이 챕터에서는 정보 은닉(캡슐화) 의 장점에 대해 설명하고 있다.

• 시스템 개발 속도를 높인다.
  • 여러 컴포넌트를 병렬로 개발 가능하기 때문
• 시스템 관리 비용을 낮춘다.
  • 다른 컴포넌트로 교체하는 부담이 적어진다.
• 성능을 높여주진 않지만, 성능 최적화에는 도움을 준다.
  • 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화할 수 있음.
• 소프트웨어 재사용성을 높인다.
• 큰 시스템을 제작하는 난이도를 갖춰준다.

접근 제어자(private, public, protected)

접근 제어자를 잘 써야한다.
사실 이제껏 private, public 두개만 사용했지 protected는 활용 빈도가 지극히 낮았던게 나의 코드였다.

여기서 말하는 원칙을 준수하려면 모든 클래스와 멤버의 접근성을 가능한 좁혀야 한다.

접근 범위가 좁은 순서

• private : 멤버를 선언한 가장 바깥의 클래스에서만 접근 가능
• package-private: 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다.
  • 접근 제한자를 명시하지 않았을 때 적용되는 접근 수준(interface는 public)
• protected: package-private의 접근 범위를 포함하며 상속받는 하위 클래스에서도 접근할 수 있다.
• public: 그냥 다 접근 가능

근데 나는 여기중에서 package-private를 쓰지않고 도메인을 더 분리하여 일급 컬렉션을 사용하면서 호출하는식으로 관리하는 것이 더 좋을 것 같다는 생각.

결국 public을 많이 사용하면 할수록 점점 코드가 뚱뚱해진다.

🤷‍♂️ 그렇다는건 또 분리를 해야한다는 것 ❗❗❗

접근 제어자 범위를 늘릴 때,
테스트를 하기 위해서 접근 제어자의 범위를 늘려주는 것은 하나의 방법이 될 수 있겠지만
인터페이스를 사용해서 값을 할당하는 strategy 패턴을 고려하는게 좋다고 생각한다.
이것도 뼈저리게 느낀 이번챕터..

public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.
public 가변 필드를 갖는 클래스라면 스레드 안전하지 않다. 그 클래스는 이 필드를 통제할 통솔력이 없다. 밖에서도 참조가 가능하기 때문에 불변을 보장할 수도 없다.
상당히 좋지 않은 방식... 그래서 DTO를 사용할 때 다 private로 기본 가져가는것이 이유중 하나일 수 있다.

이 책에서는 상수용public static final 외에는 public 필드를 가져서 안된다고 하는데 내가 생각할때는 이 마저도 남용할 수 있는 우려가 있기 때문에 private로 바꿔서 해당 클래스에서만 사용하게 해야 좋은 것 같다. 사용 빈도가 많다면 Enum을 만들어서 상수를 관리하자.

public 클래스에서는 public 필드 말고 접근제어자 메소드를 사용

이것이 dto에서 쓰는 기본 원칙이다.

class Class {
    public int x;
    public int y;
}

이러면

class Main {
    public static void main(String[] args) {
        Class class = new Class();
        class.x = 1;
    }
}

데이터에 직접 위의 코드처럼 할당이 가능해서 캡슐화의 이점을 사용할 수 없다.
그래서 필드를 private 변경하고 get, set 메서드를 사용한다.

class Class {
    private int x;
    private int y;

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }

    public void setX(int x) {
        this.x = x;
    }

    public void setY(int y) {
        this.y = y;
    }
}

이렇게 말이다.

불변 필드를 노출하게 되면 원하는 데이터가 정형화되어 나올 수 있는 환경이 파괴되기 때문에 접근제어자를 고민하면서 구현하자❗