Valuable

가비지 컬렉터

뭐지?

C나 C++같은 언매니지드 언어는 OS 레벨의 메모리의 직접 접근해서 메모리를 관리한다.

자바는 OS위의 JVM위에서 돌아간다. 이 JVM이 알아서 메모리 상에 필요하지 않은 데이터를 해제하여 공간을 확보해준다.

• JVM의 메모리 구조
  • 스택
    • 힙 영역에 생성된 객체를 참조하기 위한 값들이 할당된다.
    • 메서드 작업에 필요한 메모리 공간
      • 지역변수, 파라미터 등
  • 힙
    • 인스턴스가 생성된다.

예시

지역변수로 String 변수를 만들고 값을 넣으면, 참조변수는 스택에 할당되고 String 리터럴 값은 힙 영역에 할당되게 된다.

String str = "heap";

자바에서는 문자열에 어떤 다른 문자열을 더하면 원래 주소에 더해지는게 아니라, 새로운 인스턴스를 만들어 다른 주소를 참조하게 된다.

str += "123";

이처럼 더하게 되면 힙 영역에는 2개의 String 리터럴이 존재하는 것이다.

이때, 더 이상 참조하지 않는 "heap" 리터럴을 Garbage Collector가 삭제해주는 것이다.

이렇게 더 이상 참조하지 않는 객체를 Unreachable Object라고 한다.

동작

Mark → Sweep

• Mark
  • GC가 스택의 모든 변수를 스캔하면서 참조하는 오브젝트를 찾는다. 참조한 오브젝트가 참조하는 오브젝트까지 다 마킹한다.
• Sweep
  • Mark 되어있지 않은 힙의 오브젝트들을 지운다.

자바의 정석 예제 13-20

다중 쓰레드를 사용하여 가비지 컬렉터를 간단히 흉내내본 예제이다.

메모리 공간을 나누지 않았고, Unreachable Object 를 삭제하는게 아니라 시간에 따라 공간을 확보하는 식이다.

public class GarbageCollector extends Thread {
    final static int MAX_MEMORY = 1000;
    int usedMemory = 0;

    @Override
    public void run() {
        while (true) {
            try {
                Thread.sleep(10 * 1000);
            } catch (InterruptedException ie) {
                System.out.println("Awaken by interrupt()");
            }

            gc();
            System.out.println("Garbage Collected. Free Memory :"+freeMemory());
        }
    }

    public void gc() {
        usedMemory -= 300;
        if (usedMemory < 0) usedMemory = 0;
    }

    public int totalMemory() { return MAX_MEMORY; }
    public int freeMemory() { return MAX_MEMORY - usedMemory; }
}

• 최대 메모리는 1000이라고 한다.
• 10초를 sleep하고, gc()를 실행한다.
  • 사용중인 메모리를 300감소한다.

public class GarbageCollectorTest {
    public static void main(String[] args) {
        GarbageCollector gc = new GarbageCollector();
        gc.setDaemon(true);
        gc.start();

        int requiredMemory = 0;

        for (int i = 0; i < 20; i++) {
            requiredMemory = (int) (Math.random() * 10) * 20;

            if (gc.freeMemory() < requiredMemory || gc.freeMemory() < gc.totalMemory() * 0.4) {
                gc.interrupt();
                try {
                    gc.join(100);
                } catch (InterruptedException ie) { }
            }

            gc.usedMemory += requiredMemory;
            System.out.println("gc.usedMemory = " + gc.usedMemory);
        }
    }
}

• gc 객체를 데몬 쓰레드로 만들었다.
  • 데몬 쓰레드는 일반 쓰레드가 모두 종료되면 자동으로 종료되는 쓰레드이다.
    • 데몬 쓰레드로 지정하지 않으면, for문을 다 돌고 메인 쓰레드가 종료되어도 gc는 다른 쓰레드에서 계속 실행되게 될 것이다.
• 랜덤 값을 메모리 사용량으로 계속 넣는다.
• 여유공간이 필요공간보다 적거나, 여유공간이 40% 미만이면 잠자고 있는 가비지 컬렉터를 깨운다.
  • 깨우지 않더라도 10초마다 작동한다.
• 깨우는 부분을 보면 interrupt() 외에도 join() 메소드가 있다.
  • gc를 깨우고 가비지 컬렉션이 시작되기 전에 메인 메소드에서 또 추가를 할 수 있으므로 기다릴 시간을 주는 것이다.
  • join()에 지정된 시간동안 작업을 수행하고 호출장소로 돌아온다.
    • 지정된 시간동안은 메인 쓰레드가 수행되지 않는 것이다.

gc.usedMemory = 20
gc.usedMemory = 20
gc.usedMemory = 20
gc.usedMemory = 60
gc.usedMemory = 100
gc.usedMemory = 120
gc.usedMemory = 160
gc.usedMemory = 200
gc.usedMemory = 380
gc.usedMemory = 520
gc.usedMemory = 520
gc.usedMemory = 640
Awaken by interrupt()
Garbage Collected. Free Memory :660
gc.usedMemory = 340
gc.usedMemory = 360
gc.usedMemory = 460
gc.usedMemory = 520
gc.usedMemory = 640
Awaken by interrupt()
Garbage Collected. Free Memory :660
gc.usedMemory = 420
gc.usedMemory = 580
gc.usedMemory = 580

Process finished with exit code 0

• 실행 결과는 이런식으로 나온다.

참고

https://yaboong.github.io/java/2018/06/09/java-garbage-collection/

일반적으로 웹에서 사용하는 프로토콜인 HTTP는 stateless 프로토콜이다. 따라서 로그인 상태를 유지하기 위해서는 추가적인 방법이 필요하다.

로그인 상태를 유지하기 위한 방법 중 하나인 쿠키 세션 방식을 알아보자.

그 외에, 사용자 분석과 광고, 개인화 등을 위해 쓰이기도 한다.

쿠키

클라이언트가 로그인 인증(Authorization)을 서버로 보내면, 서버는 쿠키가 있는지 확인하고, 없다면 쿠키를 생성해서 응답 요청에 담아서 보낸다.

응답 요청에서 쿠키를 받은 클라이언트는 브라우저의 쿠키 저장소에 쿠키를 저장하고, 다음 요청 때마다 쿠키를 같이 보낸다.

그러면 서버는 요청 헤더에 있는 쿠키를 보고 서버 내부에 있는 쿠키와 일치하는게 있으면 해당 사용자로 인식하게 된다. 

쿠키는 4KB이하의 String으로 이루어져 있다.

쿠키의 적용을 받는 경로, 유효기간 등을 정할 수 있다.

세션

로그인 상태 유지를 쿠키로 하고, 사용자의 아이디와 비밀번호를 쿠키에 저장한다면, 쿠키가 유출될 경우 다른 사용자가 쿠키를 사용해서 로그인 할 수도 있다.

세션은 이런 쿠키의 취약점을 보완할 수 있다.

세션은 비밀번호 같은 인증정보를 서버쪽에 저장한다. 그리고 클라이언트에게 주는 쿠키에는 사용자를 식별할 수 있는 세션 ID를 저장한다.

클라이언트는 세션 ID를 요청에 같이 보내고, 서버는 세션 ID를 통해 인증된 사용자인지 판별한다.

서버 쪽에는 유저 이름, 만료기한 등의 정보가 저장된다.

세션은 쿠키를 사용하지만, 사용자의 정보를 브라우저가 아닌 서버에서 관리한다. 클라이언트 쪽에서 관리하는 것 보다는 보안상 유리하지만, 세션을 사용자 수만큼 생성하므로, 사용자가 많아질수록 서버에 부하가 크다.

세션은 timeout이 되거나, 로그아웃하면 서버에서 삭제된다.

HTTP가 뭐냐?

• TCP/IP 네트워크 아키텍처에서 어플리케이션 계층에서 사용하는 프로토콜이다.
• 자신이 보내고자 하는 데이터에 시작라인과 헤더 등을 붙여 목적지에 전송한다.
• 예를들어 구글에 http를 검색하면 GET메소드, path= /search?q=http , version의 start-line과 헤더정보가 붙어 서버로 전송된다.
• GET메소드는 보통 조회를 위해 사용하고, 포함되는 데이터는 없이 요청만 한다.
• http프로토콜은 이런식이 된다. 
• HTTP의 특징 중 하나로는 Stateless라는 것이다.

Stateless

• 서버가 클라이언트의 상태를 보존하지 않는다는 뜻이다. 클라이언트의 상태라는 것은 로그인 여부나 해당 클라이언트로부터 이전에 들어온 요청 등을 말한다.
• 
• stateless 특징때문에 클라이언트는 한번에 요청에 모든 정보를 담아서 보내야 한다.
• 
• 상태를 보존하지 않기 때문에 HTTP만으로는 로그인을 유지할 수 없다. 쿠키/세션 등을 이용해서 로그인을 유지하는 방법이 있다.
• 이렇게만 들으면 왜 stateless로 만든거지, 별로 아닌가 라고 생각할 수도 있다.
• 하지만 stateless 특성은 큰 이점을 가진다.
  • 상태를 유지한다면, 이전에 데이터를 보냈던 해당 서버하고만 통신을 할 수 있다.
    • 같은 서비스를 제공하더라도 물리적인 서버가 여러대 존재할 수 있다.
    
    • 일련의 요청 중에 서버에 장애가 난다면 서버에 처음부터 다시 보내야한다.
  • 상태를 유지하지 않는다면, 특정 서버와 클라이언트에 의존하지 않고 통신할 수 있다.
    • 서버 부하에 따라 다른 서버로 요청을 보내 유동적으로 처리 할 수 있다.
    • 트래픽이 많아졌을 때, 응답 서버를 늘리기가 쉽다는 장점이 있다.
• 단점은 요청 데이터의 크기가 크다. 따라서 매 요청마다 요청과 응답에 많은 네트워크 자원을 사용하게 된다.

자바를 기준으로 설명합니다. 하지만 객체지향언어에선 대부분 비슷할 것이라고 생각됩니다.

본인이 웹 개발을 공부하며 느끼고 이해한 내용에 대해 말합니다.

문법적으로 먼저 보면, 인터페이스는 상수와 추상메소드만 존재하는 추상클래스이다.

추상메소드라는 것은 메소드의 선언부만 있고, 몸통 부분은 없는 메소드이다.

(java8부터? 유지보수의 편의를 위해 default, static메소드 등도 포함되었다)

public abstract class MyInterface {
		public abstract void run();
}

// 실제로 인터페이스는 인터페이스 키워드를 사용한다.
public interface MyInterface {
		public void run(); // 컴파일러가 추상메소드로 바꿔준다.
}

이렇게 얘기해서는 감이 잘 안올 것이다.

먼저 추상화와 다형성에 대해 생각해보자.

추상화

• 예를들어 일반적인 컴퓨터를 사용할 때는 윈도우와 Mac같은 GUI OS를 사용한다.
  • 이 OS를 뜯어보면 실제 로직은 커널을 조작하는 명령어가 있을 것이다.
  • 또 이 명령어는 전기 신호로 변환되어 cpu에서 동작할 것이다.
• 이렇게 전기 신호를 명령어로 추상화하고, 명령어를 다시 GUI 환경으로 추상화했다.
• 이런 과정을 추상화라고 한다. 추상화 단계의 최상단에 있는 사용자는 내부 로직이 바뀌더라도 이전과 동일하게 사용할 수 있다.
• 애플의 인텔 맥과 ARM 맥은 사용자 입장에서 큰 변화 없이 동일하게 사용할 수 있다.

다형성

한 가지 타입으로 여러가지 구현체를 사용할 수 있는 것이다.

• 예를들어 닌텐도 스위치를 쓴다고 하자.
  • 마리오 게임용 닌텐도 스위치, 젤다 게임용 닌텐도 스위치를 따로 사지 않아도 닌텐도 스위치 하나에서 모든 게임을 동작시킬 수 있다.
• 브라우저도 마찬가지이다.
  • 네이버용 브라우저, 구글용 브라우저, 유튜브용 브라우저 따로 만들지 않는다. 한가지 브라우저로 모든 웹사이트를 이용할 수 있다.
• 자동차 운전면허도 현대 운전면허, 포드 운전면허, 벤츠 운전면허가 따로 존재하지 않는다.
• 사용자는 각 상황에 맞는 스위치, 브라우저, 운전면허를 알 필요가 없다. 대표적인 하나만 알고 있으면 되는거다.

결론

• 그래서 인터페이스를 왜 쓰느냐?

많은 이유가 있겠지만 본인이 쓰면서 가장 몸소 느낀바는 다형성이다.

• 그럼 다형성은 왜 쓰느냐?

유지보수의 편의를 위해서다. 기존의 코드의 로직이 변경될 때 변경되는 부분을 최소화 시키기 위해 한단계 추상화 하는 것이다.

인터페이스 사용 예시

인터페이스를 사용했을 때, 어떤 식으로 유지보수가 편해지는지를 알아보자.

인터페이스를 사용하지 않을 때

• 사용자와, TV가 있다고 하자.
  • tv는 samsung tv와 lg tv가 있고 전원 on/off, 채널 up/down 기능이 있다.

class SamsungTv {
    private boolean power;
    private int channel;

    public void power() {
        power = !power;
    }

    public void channelUp() {
        channel++;
    }

    public void channelDown() {
        channel--;
    }
}

class Client{
    public static void main(String[] args){
        SamsungTv tv = new SamsungTv();
        
        //power on
        tv.power();

        tv.channelUp();
        tv.channelUp();
    }
}

• 이렇게 클라이언트가 SamsungTv를 잘 사용하고 있었는데, 새로운 LG TV가 나와서 바꾸기로 하자.

class LgTv {
  private boolean power;
  private int channel;

  public void switchPower() {
      power = !power;
  }
    
  public void increseChannel() {
      channel++;
  }

  public void decreaseChannel() {
      channel--;
  }
}

• 새로나온 LG TV를 보니, 기존 삼성 TV와 하는 역할은 같지만 작동 방식(메소드)가 완전히 달라졌다.
• 따라서 클라이언트의 메소드를 사용하는 부분과 클래스를 선언하고 인스턴스를 생성한 부분을 모두 바꿔줘야한다.

class Client{
  public static void main(String[] args){
      LgTv tv = new LgTv();
    
      //power on
      tv.switchPower();

      tv.increaseChannel();
      tv.decreaseChannel();
  }
}

• TV가 한번 바뀔 때마다. 선언부, 메소드 사용하는 코드를 전부 바꿔야 했다.
• 여러사람이 작업하다보면 기존의 규칙을 무시하고 작업하는 경우도 있고, 코드가 몇천줄이 넘어가는 경우가 생길 수도 있다.
• 최악의 상황에는 일일히 다 바꿔야한다.

인터페이스를 사용할 때

• 인터페이스를 사용하게되면 위에서 겪었던 대부분의 문제를 해결할 수 있다.
• 우선 TV라는 인터페이스를 만든다.

public interface Tv {
    public void power();
    public void channelUp();
    public void channelDown();
}

• 이 인터페이스를 구현하는 삼성 TV 클래스를 만들자.

public class SamsungTv implements Tv {
    private boolean power;
    private int channel;
    
    public void power() {
        power = !power;
    }

    public void channelUp() {
        channel++;
    }

    public void channelDown() {
        channel--;
    }
}

• 이제 클라이언트에서 TV를 사용할 때에는 Tv 인터페이스형(참조변수 타입)을 사용하면 된다.

public class Client {
    public static void main(String[] args) {
        Tv tv = new SamsungTv();
        
        tv.power();
        tv.channelUp();
        tv.channelDown();
    }
}

• 새로운 TV를 만들어야한다면 이제 Tv 인터페이스를 구현하면 된다.

public class LgTv implements Tv {
  private boolean lgPower;
  private int lgChannel;

  public void power() {
      lgPower = !lgPower;
  }

  public void channelUp() {
      lgChannel++;
  }

  public void channelDown() {
      lgChannel--;
  }
}

• 인터페이스를 쓰면 메소드 명이 변경될 일이 없기 때문에 사용자는 변경된 사용방법(메소드)를 새로 알아야 필요가 없어졌다.

public class Client {
  public static void main(String[] args) {
      Tv tv = new LgTv();
        
      tv.power();
      tv.channelUp();
      tv.channelDown();
  }
}

• Tv 타입의 참조변수에 들어가는 인스턴스만 바꿔주면 다른 코드는 전혀 변경하지 않아도 된다.
• 여기서는 아주 작고, 단순한 문제를 다뤘지만, 여러가지 클래스의 포함관계가 복잡하게 얽혀있을 때 다형성은 힘을 발휘한다.

Next step…

인터페이스를 사용하면, 구현체가 바뀌더라도 유연하게 대응할 수 있다.

또, 구현을 하는 클래스에 대해 어느정도의 가이드 라인을 제공해주는 역할도 한다.

하지만 여전히 코드를 바꿔야하는 부분이 존재한다.

제어의 역전(IoC)가 제대로 일어나지 않았고, SOLID원칙의 OCP, DIP 원칙에 위배된다.

이 문제를 해결하기 위해 의존성 주입(DI)을 사용할 수 있다.

https://docs.google.com/presentation/d/1KoGEpn3wO4cAXKkOQSARFJFMSlHalQdyBQ-XtjZyhhw/edit?usp=sharing