자바 변수의 종류와 메모리 영역

public class VariableScopeExam {
    int globalScope = 10;    // 인스턴스 변수
    static int staticVal = 7;    // 클래스 변수(= static 변수)

    public void scopeTest(int value){    // 매개변수
        int localScope = 20;    // 지역변수

        System.out.println(globalScope);
        System.out.println(localScope);
        System.out.println(value);

    }
}

선언 위치에 따라 변수는 선언된 위치에 따라 클래스변수, 인스턴스변수, 지역변수로 나눌 수 있다.

메모리 공간(Runtime Data Area)은 크게 Method(Static) 영역, Stack 영역, Heap 영역으로 구분되고 데이터 타입(자료형)에 따라 각 영역에 나눠서 할당 되게 된다.

1) Method(Static) 영역

• 클래스와 인터페이스 대한 런타임 상수 풀, 멤버 변수(필드), 클래스 변수(Static 변수), 상수(final), 생성자(constructor)와 메소드(method) 등을 저장하는 공간이다.
• 클래스가 로딩될 때 생성되며 static 메모리에 있는 데이터들은 프로그램이 종료될 때까지 어디서든 사용이 가능하다.

✏️ 여기서 static이 붙지 않은 일반 인스턴스 변수들은 static 영역에 들어가지 않으며, 전역변수와 정적 맴버 변수(static 으로 선언되는 것)들의 데이터를 저장한다고 기억하고 있으면 된다.

2) Stack 영역

• 스택 영역은 기본 자료형을 생성할 때 저장하는 공간으로, 임시적으로 사용되는 변수나 정보들이 저장되는 영역이다.
• 참조 자료형은 참조값만 저장한다. 이 참조값은 heap 영역에 존재하는 인스턴스(객체)를 가르키는데 사용한다.

3) Heap 영역

• 참조형(Reference Type)의 데이터 타입을 갖는 객체, 배열 등은 Heap 영역에 저장된다.

✏️ new를 통해 인스턴스 객체를 생성했을 때, heap 영역에는 생성된 객체가 올라가고, Stack 영역에는 해당 객체에 대한 주소 값(Reference)이 저장하는 것이다.

static

static은 '정적인' 이라는 뜻을 가지고 있으며, static이 앞에 붙는 변수나 메서드는 어떤 객체에 소속되는 것이 아닌, 클래스에 고정되어 있는 변수나 메서드이다.

따라서 객체 생성 없이 사용할 수 있으며, 위에서 설명하였듯이 메모리에 고정적으로 할당된다. 프로그램이 시작되면 메모리의 static 영역에 적재되고, 프로그램이 종료될 때 해제된다.

여기서 주의하여할 점은, static 메서드 내에서는 인스턴스 변수를 사용할 수 없다는 것이다. 이는 static한 메서드가 사용되는 시점에 해당 클래스가 인스턴스화되지 않았을 수도 있기 때문이다. 쉽게 말하면 static 메서드는 는 객체 생성 없이 사용할 수 있는데, 인스턴스 변수는 객체의 속성이므로 사용할 수 없는 것이다. 따라서 static 메서드 내에서 인스턴스 변수를 사용하면 컴파일 오류가 발생한다!

또 static한 필드는 인스턴스를 생성할 때 만들어지는 것이 아니라고 하였으므로, 값을 저장할 수 있는 공간도 하나밖에 없다. 즉 값을 공유하는 것이다. 그래서 같은 클래스에 대해 2개의 인스턴스를 생성하여 static 변수에 각각 다르게 값을 할당하여도 공유하기 때문에 최종적으로 할당한 값이 출력될 것이다.

_변하지 않는 값이라면 final을 붙여 생성해야 한다. _

지금부터 내가 수강한 강의 중 수료증이 발급된다면 업로드할 예정이다. 이 강의는 2021년도 개발을 처음 시작하였을 때 들었지만, 당시에는 이해를 하나도 못했다. 그래서 지금 2024년에 재수강하여 최근에 완강하였다.

강의에 대한 후기는, 해당 로드맵의 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술 라는 첫번째 무료강의에 대한 연장선상으로 스프링에 대한 기본적인 원리에 대한 강의였다. 그래서 첫번째 무료 강의를 듣는 것을 추천하며, 무료강의 또한 퀄리티가 좋았다.

강의를 꽤 꼼꼼하게 듣는 편이라 강의노트도 잘 활용한다. 그래서 적어둔 노트를 보면서 블로그에 내 방식으로 정리를 하고 있다. 김영한 강사님을 너무 좋아해서 인프런에 올려주신 로드맵에 대한 강의를 모두 구매해버렸다. 올해 다 듣는게 목표인데, 너무 꼼꼼하게 들어서 가능할지는 모르겠다.

나는 스프링 프레임워크를 사용하면서도 왜 사용하는지 원리에 대해서 전혀 알지 못했다. 하지만 개발을 한지 2년이 조금 넘어서야, 느리더라도 깊은 공부를 해야겠다는 것을 정말 실감한다. 나와 같은 니즈를 느끼는 사람들에게 정말 적합한 강의를 선보이고 계시는 것 같아서 열성팬이 되어버렸다.

로드맵을 추천해주신 직장 동료분에게 감사하다. 앞으로도 느리지만 완강하여 수료증을 보면서 보람을 느끼고 싶다.

스프링 컨테이너(Spring Container)

스프링 컨테이너는 자바 객체, 빈(Bean)의 생명 주기를 관리하며, 생성된 빈에게 추가적인 기능을 제공하는 것이다.

✏️ 스프링 컨테이너 생성

AppConfig.class

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    //중복을 방지하고, 역할과 구현 클래를 한 눈에 구분할 수 있다.
    @Bean
    public  MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();

        //할인 정책이 바뀌었다.
        return new RateDiscountPolicy();
    }
}

• 그림과 같이 빈 이름은 메서드 이름을 사용한다.
• @Bean(name="myBean") 과 같이 빈 이름을 직접 부여할 수도 있지만, 빈 이름은 항상 다른 이름을 부여해야 한다.

✏️ 스프링 빈 조회

스프링 컨테이너에 실제로 스프링 빈이 잘 등록되었는지 확인해보자.

ApplicationContext applicationContext =
                     new AnnotationConfigApplicationContext(AppConfig.class);

• ApplicationContext 인터페이스를 스프링 컨테이너라 하며 AnnotationConfigApplicationContext는 스프링 컨테이너 인터페이스의 구현체이다.

BeanFactory는 스프링 컨테이너의 최상위 인터페이스로 빈을 관리하고 조회하는 역할을 담당하며 getBean() 을 제공한다.

• ApplicationContext는 기능을 상속받아 빈 관리기능 + 편리한 부가 기능을 제공한다. 모두 스프링 컨테이너라 한다.
• ApplicationContext가 제공하는 부가기능에는 메시지소스를 이용한 국제화 기능, 환경변수, 이벤트, 리소스 조회가 있다.

스프링 빈을 찾는 기본적인 조회 방법으로 다음과 같이 있다.

• ac.getBean(빈이름, 타입)
• ac.getBean(타입)

이를 활용하여 빈을 조회하는 테스트 코드를 작성하였다.

public class ApplicationContextBasicFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName(){
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        System.out.println("memberService = " + memberService);
        System.out.println("memberService.getClass() = " + memberService.getClass());
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
    @Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType(){
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2(){
        // 구현체로 확인하면 유연성이 떨어지지만 필요한 경우도 있음
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("빈 이름으로 조회X")
    void findBeanByNameX(){
        //MemberService memberService = ac.getBean("xxxxx", MemberServiceImpl.class);
        // ()-> 뒤의 로직 실행시, 다음과 같은 Exception 발생하는지에 대한 확인
        assertThrows(NoSuchBeanDefinitionException.class,
                        () -> ac.getBean("xxxxx", MemberServiceImpl.class));
    }
}

마지막 테스트는 조회 빈이 없는 경우 NoSuchBeanDefinitionException 예외 발생을 확인한 것이다.

이 게시물은 인프런 김영한 강사의 스프링 핵심 원리 - 기본편 을 듣고 작성하였습니다.

제어의 역전 IoC(Inversion of Control)

: 쉽게 말하면 Config 클래스가 프로그램에 대한 제어 흐름을 가져가는 것이다. 예를들어 Impl 클래스가 직접 로직을 수행하지만 호출하는 인터페이스의 어떤 구현 객체를 실행시킬지 제어하는 것이다.

이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라고 하며, 이는 객체지향 설계의 5가지 원칙 중 대표적으로 SRP, DIP, OCP를 지키기 위함이다.

✏️** SRP 단일 책임 원칙** : 한 클래스는 하나의 책임만 가져야 한다.

• 구현 객체를 생성하고 연결하는 책임은 Config가 담당
• 클라이언트 객체(ex Impl클래스)는 실행하는 책임만 담당
• SRP 단일 책임 원칙을 따르면서 관심사를 분리함

[역할과 구현의 분리] : 역할과 구현으로 구분하면 세상이 단순, 유연해지며 변경도 편리해진다.

클라이언트는 대상의 역할만 알면 된다. 클라이언트는 구현 대상의 내부 구조를 몰라도 된다. 클라이언트는 구현 대상의 내부 구조가 변경되어도, 대상 자체를 변경해도 영향 받지 않는다.

자바에서도 이런 특징을 활용한다.

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스, 구현 객체

객체를 설계할 때 역할과 구현을 명확히 분리한다. 객체를 설계할 때 역할(인터페이스)를 먼저 부여하고, 그 역할을 수행하는 구현 객체를 만든다.

✏️** DIP 의존관계 역전 원칙** : 추상화가 아닌 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나이다.

public class OrderServiceImpl implements OrderService {
 //  DiscountPolicy 인터페이스의 구현객체 변경으로 코드 수정해야함. Fix => Rate
 //  private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

     private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
 }

이는 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다. 따라서 DIP위반, 변경해야 하기 때문에 OCP 모두 위반한다. 인터페이스에만 의존하도록 변경하면 아래와 같다.

애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 Config 클래스를 만든 뒤, 생성자 주입을 사용한다. 빈 Bean 활용을 통한 설정은 아래에 추가적으로 소개하고, 순수 코드로 작성하였다.

public class AppConfig {
     //FixDiscountPolicy 구현체 사용
     public OrderService orderService() {
         return new OrderServiceImpl(new FixDiscountPolicy());
     }
}

public class OrderServiceImpl implements OrderService {
     private final DiscountPolicy discountPolicy;

     public OrderServiceImpl(DiscountPolicy discountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
     }
}

AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의 존관계를 주입했다. 이렇게해서 DIP 원칙을 따르면서 문제도 해결했다.

✏️** OCP 개방 폐쇄의 원칙** : 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다

• 다형성을 사용하고 클라이언트가 DIP를 지킨다.
• 애플리케이션을 사용 영역과 구성 영역으로 나눈다.
• 위의 예시에서 AppConfig가 의존관계를 FixDiscountPolicy RateDiscountPolicy 로변경해서 클라이언트코드에 주입하므로 클라이언트 코드는 변경하지 않아도 되므로, 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀 있다!

의존관계 주입 DI(Dependency Injection)

: 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각해야 한다.

✏️** 정적인 클래스 의존관계** 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있다. 그러나 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 주입될지 알 수 없다.

✏️ 동적인 객체 인스턴스 의존관계 : 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 그 참조값을 전달해서 연결하는데, 이렇게 클라이언트에 전달해서 서버와 실제 의존관계가 연결되는 것을 의존관계 주입이라 한다. 즉, 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경 할 수 있다.

DI 컨테이너 (IoC 컨테이너)

: Config 설정 클래스처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 DI 컨테이너라고 한다. 또는 어샘블러, 오브젝트 팩토리 등으로 불리기도 한다.

[스프링으로 전환하기] 위에서는 순수한 자바 코드만으로 DI를 적용했다. 스프링을 사용하면 다음과 같이 수정할 수 있다. 아래와 같이 하면 스프링 컨테이너에 스프링 빈으로 등록한다.

@Configuration
public class AppConfig {

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

• 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이 라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록하며, 이를 스프링 빈이라 한다.
• 스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. 스프링 컨테이너에 객체를 스프링 빈으로 등록 하고, 스프링 빈을 찾아서 사용할 수 있다.

📍 스프링 컨테이너를 통 해서 필요한 스프링 빈(객체)를 찾는 법

ApplicationContext applicationContext 
        = new AnnotationConfigApplicationContext(AppConfig.class);

OrderService orderService = applicationContext.getBean("orderService", OrderService.class);

ApplicationContext 를 스프링 컨테이너라 하며, applicationContext.getBean() 메서드를 사용 해서 찾을 수 있다.

동시성 이슈

스레드는 cpu 작업의 한단위이다. 멀티스레드 방식은 멀티태스킹을 하는 방식 중, 한 코어에서 여러 스레드를 이용해서 번갈아 작업을 처리하는 방식이다.

멀티 스레드를 이용하면 공유하는 영역이 많아 프로세스방식보다 context switcing(작업전환) 오버헤드가 작아, 메모리 리소스가 상대적으로 적다는 장점이 있다.

(프로세스는 운영체제로부터 자원을 할당받은 작업의 단위이며, 스레드는 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위이다.)

하지만 자원을 공유해서 단점도 존재한다. 그게 바로, 동시성(concurrency) 이슈이다.

여러 스레드가 동시에 하나의 자원을 공유하고 있기 때문에 같은 자원을 두고 경쟁상태(raceCondition) 같은 문제가 발생하는 것이다.

HashMap vs ConcurrentHashMap

HashMap은 내부에서 동기화를 제공하지 않기 때문에 단일 스레드(single-threaded) 애플리케이션에 적합하다.

ConcurrentHashMap은 내부에서 동기화(synchronization)를 제공하여 여러 개의 스레드가 동시에 맵에 접근하고 수정할 수 있도록 하기 때문에 동시 다중 스레드(concurrent multi-threaded) 애플리케이션에 적합하다.

Java의 동시성 문제

Java는 멀티 스레드 프로그래밍이 가능한 언어입니다. JVM은 보통 어떤 서버(기기) 상에서 실행되고 있는 프로세스를 말합니다. 이러한 JVM은 최소 한 개(main 스레드) 이상 여러 스레드를 가질 수 있습니다.

그렇다면 많은 스레드가 공유한 자원에 동시에 접근하게 되면 어떤 문제가 발생할 수 있을까요?

public class Main {

    public static void main(String[] args) {
        Counter counter = new Counter();

        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                counter.increment();
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                counter.increment();
            }
        });

        thread1.start();
        thread2.start();

        try {
            thread1.join();
            thread2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("Final Counter Value: " + counter.getCount());
    }

    public static class Counter {
        private int count = 0;

        public void increment() {
            count++;
        }

        public int getCount() {
            return count;
        }
    }
}

위 코드만 간단하게 본다면, 정상적으로 동작했을 경우 count의 수는 20000이 되어야 합니다. 실제 코드를 실행하고 결과를 확인 하면 아래와 같습니다.

Final Counter Value: 16950

매 실행마다 다른 결과값을 받아 볼 수 있습니다. 그 이유는 Java의 특성인 멀티 스레드 프로그래밍에 있습니다. 두 스레드가 하나의 자원에 동시에 접근하며, 동기화 되지 않은 데이터의 결과입니다.

참고

[동시성 이슈] HashMap vs ConcurrentHashMap [Java] 멀티 스레드환경의 동시성 이슈 그리고 해결방법 [Java] ConcurrentHashMap 이란 무엇일까? 완전히 정복하는 프로세스 vs 스레드 개념 동시성에 대한 해결방법을 알아보자

2) Java 폴더를 우클릭하여 Mark directory as를 통해 source root로 설정한다.

동기는 요청한 작업에 대해 완료 여부를 따져 순차대로 처리한다.

비동기는 동시에 일어나지 않는다는 의미로 요청한 작업에 대해 완료 여부를 따지지 않기 때문에 자신의 다음 작업을 그대로 수행한다.

블록(Blocking) / 논블록(Non-Blocking)

동기/비동기가 전체적인 작업에 대한 순차적인 흐름 유무라면, 블로킹/논블로킹은 전체적인 작업의 흐름 자체를 막냐 안 막냐로 볼 수 있다.

논블록킹을 방식은 어떤 작업을 실행하여도 대기하지 않고 다른 작업을 할 수 있다. 비동기와 비슷해보이는데, 두 개념이 조합되어 사용된다.

• Sync Blocking (동기 + 블로킹)
• Async Blocking (비동기 + 블로킹)
• Sync Non-Blocking (동기 + 논블로킹) 
• Async Non-Blocking (비동기 + 논블로킹)

✏️ 다음 #1. 동기, 비동기, 블록, 논블록 네가지 조합에 대한 설명 #2. 큐, 스택 자료구조 #3. 프로세스, 스레드 개념과 멀티 프로세스, 멀티 스레드로 확장 #4. 자바스크립트의 동작원리

📄 참고 완벽히 이해하는 동기/비동기 & 블로킹/논블로킹 멀티 프로세스 vs 멀티 스레드 비교 💯 완전 총정리 자바스크립트 이벤트 루프 동작 구조 & 원리 끝판왕 자바스크립트 동기, 비동기?