week 2 jisoo - GANGNAM-JAVA/JAVA-STUDY GitHub Wiki

• 프로세스란 '실행 중인 프로그램'. 프로그램을 실행하면 OS로부터 실행에 필요한 자원(메모리)을 할당받아 프로세스가 된다.
• 프로세스는 프로그램 수행에 필요한 데이터, 메모리등의 자원과 쓰레드로 구현되어 있다.
• 즉 쓰레드는 프로세스의 자원을 이용해서 실제로 작업을 수행
• 모든 프로세스에는 최소 하나 이상의 쓰레드가 존재, 둘 이상의 스레드를 가진 프로세스는 멀티쓰레드 프로세스라고 한다.

• Thread클래스를 상속받는 방법

public static class ThreadTest2 extends Thread {
        public void run() {
            System.out.println(getName());
        }
    }

// 메인 메서드에서 인스턴스 생성 방법
Thread t1 = new ThreadTest2();

• Runnabele 인터페이스를 구현하는 방법 (다중 상속이 가능하여 더 일반적으로 사용)

public static class ThreadTest implements Runnable {
        public void run() {
            System.out.println(Thread.currentThread().getName());
        }
    }

// 메인 메서드에서 인스턴스 생성 방법
Thread t1 = new Thread(new ThreadTest()); // new Thread(Runnable target) 생성자 이용

• 애플리케이션에서 하나 이상의 스레드 사용시 새로운 스레드를 한개라도 생성해서 운영한다면 멀티스레드 프로그램이 됩니다.

• 스레드는 별도로 실행되는 하나의 실행이므로 동시에 여러 스레드가 실행되면 스레드들이 공유하는 자원에 대해 동기화가 발생할 수 있습니다.

만약 스레드들이 서로 침범하는 영역없이 동작한다면 동기화 문제를 고려하지 않아도 됩니다. 프로세스들 간에 대해서는 이미 OS가 별도의 프로그램으로 동작하도록 알아서 처리를 해주고 있습니다. 프로세스는 자기만에 address space 범위를 갖고있고, 다른 프로세스들이 차지하는 메모리 스페이스를 침범할 수가 없습니다.  한 프로세스 안에서 실행되는 여러개의 스레드들은 서로 공유할 수 있는 메모리 부분이 있습니다. 공유할 수 있는 부분이 있으므로, 그때 동기화문제가 발생할 수 있습니다.

동기화 문제는 스레드들간의 공유자원에 접근하는 것은 한번에 한 스레드만 가능하게 함으로써 해결할 수 있습니다. 한번에 한 스레드만 공유자원에 액세스하도록 만들어주면 동기화문제 해결이 됩니다. 자바런타임시에는 쓰레드들간 아래의 영역이 공유됩니다. 이부분에 대한 제어가 필요합니다.

아래 항목들은 스레드들간 공유되는 영역도 있고, 독립적인 영역도 있습니다. 개발자가 확인해야할 부분은 공유되는 영역 부분입니다. 모든 스레드들은 각각의 Program Counter(일종의 지시자, 다음 수행되야할 명령어가 무엇인지를 가르키고 있음.)를 가지고 있습니다.

• PC(Program Counter) 레지스터 영역: 스레드 각각이 갖고 있으므로 스레드간 독립적인 영역
• JVM 스택 영역: 지역변수, 파라미터, 리턴값, 객체 레퍼런스들이 저장되어 있는 공간. 스레드 각각이 갖고있는 따로 관리되는 독립적인 영역
• 힙 영역: 생성된 자바의 객체들이 저장되는 부분. 모든 스레드들이 접근 가능합니다. (공유되는 영역)
• 메소드 영역: 함수영역으로 각 클래스 또는 인터페이스에 런타임 컨텍스트 풀영역, 메소드 생성자를 저장하는 영역으로 모든 스레드에 의해서 공유되는 영역 입니다.
• 런타임 컨텍스트 풀 영역: 클래스 또는 인터페이스의 클래스 변수, static 변수, 클래스 객체의 레퍼런스를 저장하는 영역으로 스레드들간 공유되는 영역입니다.
• 데이터와 메소드 스택 영역: 마찬가지로 스레드들간 공유되는 영역입니다.

- 임계영역이란 멀티 스레드에 의해 공유자원이 참조할 수 있는 코드의 범위를 말합니다.

• 즉, 한번에 한 쓰레드만 접근이 가능한 영역을 임계영역이라 합니다.

• 멀티 스레드 프로그램에서 임계영역을 처리하는 경우 심각한 문제가 발생할 수 있습니다.

• 이러한 상황을 해결할 수 있는 방법이 동기화를 이용하는 것입니다.

• 동기화를 처리하기 위해 모든 객체에 락(lock)을 포함 시킵니다.

- 락이란 공유 객체에 여러 스레드가 동시에 접근하지 못하도록 하기 위한 것으로 모든 객체가 힙 영역에 생성될때 자동으로 만들어집니다. 즉, 공유 데이터가 가지고 있는 lock을 획득한 단 하나의 쓰레드만 이 영역 내의 코드 수행 가능.

공유 데이터를 사용하는 코드 영역을 임계 영역으로 지정해놓고, 공유 데이터가 가지고 있는 lock을 획득한 쓰레드는 임계 영역 내의 모든 코드를 수행하고 벗어나서 lock을 반납해야만 다른 쓰레드가 반납된 lock을 획득하여 임계영역의 코드를 수행할 수 있게 할 수 있다.

이처럼 한 쓰레드가 진행 중인 작업을 다른 쓰레드가 간섭하지 못하게 막는 것을 동기화라고 한다.

스레드를 동기화하는 방법은 여러가지가 있는데 가장 간단한 방법은 synchronized를 이용해서 임계영역을 설정하는 것이다.

가장 간단한 동기화 방법이며, 이 키워드는 임계 영역을 설정하는데 사용된다. 메서드 전체를 임계 영역으로 설정하거나, 특정 영역을 임계 영역으로 지정할 수 있다.

public synchronized void calcSum() {
	...
}

synchronized(객체의 참조변수) {
	...
}

• 두번째 방법은 메서드 내의 코드 일부를 블럭으로 감싸고 블럭 앞에 synchronized(참조변수) 를 붙이는 것이다. 이때 참조변수는 락을 걸고자 하는 객체를 참조하는 것이어야 한다.

• 이 블럭을 synchronized 블럭이라고 부르며, 이 블럭의 영역 안으로 들어가면서부터 쓰레드는 지정된 객체의 lock을 얻게 되고, 이 블럭을 벗어나면 lock을 반납한다.

• 두 방법 모두 lock의 획득돠 반납이 자동적으로 이루어지므로 임계 영역만 설정해주면 된다.

• 모든 객체는 lock을 하나씩 가지고 있으며, 해당 객체의 lock을 가지고 있는 쓰레드만 임계 영역의 코드를 수행할 수 있다.

// Object의 equals 메서드
public boolean equals(Object obj) {
    return (this == obj);
}

Object 클래스의 equals()는 위와 같은 기능으로써 이 메소드는 비교 연사자인 == 과 동일한 결과를 리턴한다. 오로지 참조값(객체의 주소값)이 같은지, 다시말하면 동일 객체인지를 확인하는 기능이다.

자바에서는 두 객체를 동등 비교할 때 equals() 메소드를 흔히 사용한다. equals() 메소드는 두 객체를 비교해서 논리적으로 동등하면 true를 리턴하고 그렇지 않으면 false를 리턴한다.

논리적으로 동등하다는것은 둘의 참조값이 다르더라도 객체 내부 value는 같다는것을 의미한다. 이 equals함수를 재정의한 대표적인 예가 String class이다. String class는 equals() 메소드를 재정의해서 번지비교가 아닌 문자열 '값'을 비교한다.

• 동일성 비교는 == 비교다. 객체 인스턴스의 주소 값을 비교한다.
• 동등성 비교는 equals() 메소드를 사용해서 객체 내부의 값을 비교한다.

객체 해시코드란 객체를 식별하는 하나의 정수값을 말한다. Object의 hashCode() 메소드는 객체의 메모리 번지를 이용해서 해시코드를 만들어 리턴하기 때문에 객체 마다 다른 값을 가지고 있다. 객체의 값을 동등성 비교시 hashCode()를 오버라이딩할 필요성이 있는데, 컬렉션 프레임워크에서 HashSet, HashMap, HashTable은 다음과 같은 방법으로 두 객체가 동등한지 비교한다.

우선 hashCode() 메소드를 실행해서 리턴된 해시코드 값이 같은지를 본다. 해시 코드값이 다르면 다른 객체로 판단하고, 해시 코드값이 같으면 equals()메소드로 다시 비교한다. 이 두 개가 모두 맞아야 동등 객체로 판단한다. 즉, 해시코드 값이 다f른 엔트리끼리는 동치성 비교를 시도조차 하지 않는다.

equals와 hashcode 메서드를 이해하기 위해서 자바에서 HashTable이 작동하는 원리를 간단히 살펴보자.

HashTable은 <key,value> 형태로 데이터를 저장한다. 이 때 해시 함수(Hash Function)을 이용하여 key값을 기준으로 고유한 식별값인 해시값을 만든다. (hashcode가 해시값을 만드는 역할을 한다.) 이 해시값을 버킷(Bucket)에 저장한다.

하지만 HashTable 크기는 한정적이기 때문에 같은 서로 다른 객체라 하더라도 같은 해시값을 갖게 될 수도 있다. 이것을 **해시 충돌(Hash Collisions)**이라고 한다. 이런 경우 아래와 같이 해당 버킷(Bucket)에 LinkedList 형태로 객체를 추가한다.

이처럼 같은 해시값의 버킷 안에 다른 객체가 있는 경우 equals 메서드가 사용된다.

HashTable에 put 메서드로 객체를 추가하는 경우

• 값이 같은 객체가 이미 있다면(equals()가 true) 기존 객체를 덮어쓴다.
• 값이 같은 객체가 없다면(equals()가 false) 해당 entry를 LinkedList에 추가한다.

HashTable에 get 메서드로 객체를 조회하는 경우

• 값이 같은 객체가 있다면 (equals()가 true) 그 객체를 리턴한다.
• 값이 같은 객체가 없다면(equals()가 false) null을 리턴한다.

위 그림에서 세 객체 (Entry<K1,V1>, Entry<K2,V2>, Entry<K3,V3>)는 서로 같은 해시값을 같는다. 따라서 hashcode() 메서드는 같은 값을 리턴한다. 하지만 서로 값이 다른 객체이기 때문에 equals() 메서드는 false를 리턴한다.

만약 equals()와 hashcode() 중 하나만 재정의 하면 어떻게 될까? 위 예에서도 봤듯이 hashcode()를 재정의 하지 않으면 같은 값 객체라도 해시값이 다를 수 있다. 따라서 HashTable에서 해당 객체가 저장된 버킷을 찾을 수 없다.

반대로 equals()를 재정의하지 않으면 hashcode()가 만든 해시값을 이용해 객체가 저장된 버킷을 찾을 수는 있지만 해당 객체가 자신과 같은 객체인지 값을 비교할 수 없기 때문에 null을 리턴하게 된다. 따라서 역시 원하는 객체를 찾을 수 없다.

이러한 이유로 객체의 정확한 동등 비교를 위해서는 (특히 Hash 관련 컬렉션 프레임워크를 사용할때!) Object의 equals() 메소드만 재정의하지 말고 hashCode()메소드도 재정의해서 논리적 동등 객체일경우 동일한 해시코드가 리턴되도록 해야한다.

Serial GC 적용을 위한 JVM 옵션 : -XX:+UseSerialGC

Serial 이란 단어의 의미인 ‘순차적인’ GC 방식이다. Young 영역에서의 GC는 이전에 설명한 방식을 사용한다. (Eden, Survivor1, Survivor2로의 이동) Old 영역의 GC는 mark-sweep-compact이라는 알고리즘을 사용한다. Serial GC 그리고 다음에 나오는 Parallel GC 를 이해하기 위해서는 Mark-Sweep-Compaction 알고리즘을 알아두어야 할 필요가 있다.

Mark-Sweep-CompactionMark-Sweep-Compaction 이란 서로다른 다양한 GC에서 사용되는 알고리즘이다. GC 대상객체를 식별하고 제거하며파편화된 메모리 영역을 앞에서부터 채워나가는 작업을 수행하게 된다.

• 사용되지 않는 객체를 식별하는 작업 (Mark)
• 사용되지 않는 객체를 제거하는 작업 (Sweep)
• 파편화된 메모리 영역을 앞에서부터 채워나가는 작업 (Compaction)
  Compaction 작업의 경우 Windows의 디스크 조각 모음을 생각하면 좋을 것이다.

Serial GC가 순차적으로 동작할 수 밖에 없는 이유는 GC를 처리하는 스레드가 하나이기 때문이다.

Parallel GC 적용을 위한 JVM 옵션 : -XX:+UseParallelGC, -XX:ParallelGCThreads (Minor GC 스레드 개수)

앞서 살펴본 Serial GC을 사용하던 시절보다 PC의 성능이 좋아졌다고 생각해보자. 메모리도 넉넉해졌고 CPU Core 도 좀 더 많아졌다. 이런 상황이라면 하나의 스레드로 동작했던 Serial GC를 멀티스레드로 실행하고 싶어질 것이다. Parallel GC는 Serial GC와 기본적인 알고리즘은 같지만, Minor GC를 처리하는 스레드를 여러개로 늘려 좀 더 빠른 동작이 가능하게한 방식이다.

Serial GC와 Parallel GC의 차이

그림을 보면 Serial GC는 GC 작업을 하는 스레드(GC Thread)가 하나이며, Parallel GC에서는 이 GC Thread가 여러개 존재한다.

이는 Parallel GC 에서의 GC 프로세스가 더 빠르게 동작할 수 있게 해주며 이러한 차이는 GC를 처리하는 동안 Java의 프로세스가 모두 멈춰버리는 Stop-The-World 현상이 나타나는 시간에도 영향을 주게된다.

즉, STW(Stop-The-World) 시간이 좀 더 적게 걸리는 Parallel GC에서의 Java 애플리케이션이 좀 더 매끄럽게 동작한다는 의미이다.

G1 GC를 이해하려면 지금까지의 Young 영역과 Old 영역에 대해서는 잊는 것이 좋다.

하드웨어가 발전되면서 Java 애플리케이션에 사용할 수 있는 메모리의 크기도 점차 켜저갔다. 하지만 기존의 GC 알고리즘들로는 큰 메모리에서 좋은 성능(짧은 STW)을 내기 힘들었기 때문에 이에 초점을 둔 G1 GC가 등장하게 되었다.

즉, G1 GC는 큰 힙 메모리에서 짧은 GC 시간을 보장하는데 그 목적을 둔다.

G1 GC는 앞서 살펴본 GC와는 다른 방식으로 힙 메모리를 관리한다. 앞서 살펴보았던 Eden, Survivor, Old 영역이 존재하지만 고정된 크기로 고정된 위치에 존재하는 것이아니며, 전체 힙 메모리 영역을 Region 이라는 특정한 크기로 나눠서 각 Region의 상태에 따라 그 Region에 역할(Eden, Survivor, Old)이 동적으로 부여되는 상태이다.

G1 GC가 적용된 JVM Heap 구조

횡단 관심사를 구현하는 툴 : 어플리케이션에서 코드가 중복되고 강력하게 결합돼 다른 로직과 분리할 수 없는 애플리케이션 로직

AOP는 문제를 해결하기 위한 핵심 관심 사항과 전체에 적용되는 공통 모듈 사항을 기준으로 프로그래밍 함으로써 공통 모듈을 여러 코드에 쉽게 적용할 수 있도록 도와주는 역할을 합니다. AOP를 구현하는 다양한 방법이 존재하지만, 기본적인 개념은 아래 그림과 같이 공통 관심 사항 코드를 비즈니스 로직을 구현한 코드안에 삽입하는 것입니다.

→ 객체 지향 프로그래밍을 보완함.

• 조인포인트 : 어플리케이션 실행 과정 내에 있는 명확한 지점. AOP를 사용해 추가 로직을 삽입할 수 있는 애플리케이션의 특정 지점
• 어드바이스 : 특정 조인포인트에 실행되는 코드로 애플리케이션 클래스 내 메서드로 정의됨.
• 포인트컷 : 애스팩트가 적용되어야 하는 곳을 판별할 수 있는 패턴을 기술
• 애스팩트 : 클래스에 캡슐화된 어드바이스와 포인트컷의 조합
• 위빙 : 애플리케이션 코드의 적절한 위치에 애스팩트를 삽입하는 과정

• 정적 AOP

• 빌드 프로세스에서 별도 단계로 이루어짐.

• 애플리케이션의 실제 바이트코드를 수정. → 결과물이 자바 바이트코드.

• 애스팩트를 조금이라도 수정하게 되면 전체 애플리케이션을 다시 컴파일해야 한다는 점.

• 즉 컴파일 시에 코드를 삽입하는 방법. AspectJ에서 사용하는 방식

• 자바 소스를 컴파일 할 때, 앙ㄹ맞은 위치에 공통 코드를 삽입하면, 컴파일 결과 AOP가 적용된 클래스 파일이 생성된다.

• 동적 AOP

• 런타임에 동적으로 위빙 프로세스가 수행됨.

• 어드바이스가 적용된 모든 객체에 대한 프록시를 생성해 필요에 따라 어드바이스를 호출할 수 있도록 하는 방식.

• 메인 어플리케이션을 다시 컴파일 하지 않아도 애플리케이션에서 전체 애스팩트를 쉽게 수정할 수 있음.

• AOP 라이브러리는 JVM이 클래스를 로딩할 때 클래스 정보를 변경할 수 있는 에이전트를 제공

• 이 에이전트는 로딩한 클래스의 바이너리 정보를 변경하여 알맞은 위치에 공통 코드를 삽입한 새로운 클래스 바이너리 코드를 사용하도록 함. 즉 원본 클래스 파일은 변경하지 않고 클래스를 로딩할 때에 JVM이 변경된 바이트 ㅗ드를 사용하도록 함으로써 AOP를 적용

스프링은 프록시를 이용하여 AOP를 구현합니다. 스프링은 Aspect의 적용대상이 되는 객체에 대한 프록시를 만들어 제공합니다. 비지니스 로직에 접근할 때 대상 객체로 바로 접근하는 게 아닌 프록시를 통해서 간접적으로 접근하게 됩니다. 이 과정에서 프록시는 공통 기능을 실행한 뒤 대상 객체의 실제 메서드를 호출하거나 또는 대상객체의 실제 메소드를 호출한 후에 공통기능을 실행합니다.
대상 타겟은 결국 빈 객체가 생성 되는데, 런타임시에 오브젝트 생성 설정에 따라서 스프링 컨테이너가 지정한 빈 객체 대한 프록시 객체를 생성하고, 원본 빈 객체 대신에 프록시 객체를 사용하게 합니다.

프록시 객체를 생성하는 방식은 대상 객체가 인터페이스를 구현하고 있느냐 없느냐 여부에 따라 달라집니다. 2가지 방식이 존재하는데 JDK Dynamic Proxy, CGLIB를 이용하여 프록시를 생성하는 방식이 있다.

스프링의 선언적 트랜잭션은 AOP를 이용하고 있다. 스프링은 @Transactional 애노테이션을 이용하면, 트랜잭션을 처리하기 위해 빈 객체에 대한 프록시 객체를 생성한다. 이 프록시 객체는 PlatformTransactionManager를 이용해서 트랜잭션을 시작한 뒤에, 실제 객체의 메서드를 호출하고, 그 다음에 PlatformTransactionManager를 이용해 트랜잭션을 커밋한다. 모든 비즈니스 메소드가 호출될때, AOP를 사용해서 트랜잭션 블록을 시작하고, 메소드의 호출이 완료될 때, 트랜잭션을 커밋하거나 롤백할 수 있다.

TransactionTemplate이 처리하는 작업을 프록시가 대신 처리해준다.

선언적 트랜잭션은 AOP를 사용하므로, 하나의 빈 객체에 대해 두 개 이상의 프록시 객체가 생성될 수 있다. (예: 트랜잭션을 위한 프록시와 개발자가 직접 구현한 AOP 프록시) 이 때, 프록시가 실행되는 순서가 중요하다면, 원하는 순서로 프록시가 적용되도록 명시적으로 AOP 순서를 지정해야 한다.

기억해야할 점은, 만약 트랜잭션 프록시 빈이 인터페이스를 구현하고 있으면, (Service interface 같은) 기본 프록시 전략은 Java Dynamic Proxy 이다. 이 의미는 즉, 프록시 객체로부터 불리는 외부 메소드 콜만 intercept 처리될 수 있다.

반면 같은 클래스 내에서, Transactional 어노테이션이 붙은 메소드를 다른 메소드가 콜하는 상황에서는 Transactional 이 적용되지 않는다. (Inner-method-call) 그리고 오로지 public method만 @Transactional 어노테이션을 사용할 수 있다.

public class BooksImpl implements Books {
  public void addBooks(List<String> bookNames) {
    bookNames.forEach(bookName -> this.addBook(bookName)); // inner-method call로 트랜잭션이 적용되지않음!
  }
  
  @Transactional
  public void addBook(String bookName) {
    Book book = new Book(bookName);
    bookRepository.save(book);
    book.setFlag(true);
  }
}

public class BooksProxy {
  private final Books books;
  private final TransactonManager manager = TransactionManager.getInstance();
  
  public BooksProxy(Books books) {
    this.books = books;
  }
  
  public void addBook(String bookName) {
    try {
      manager.begin();
      books.addBook(bookName);
      manager.commit();
    } catch (Exception e) {
      manager.rollback();
    }
  }
}

출처: https://mommoo.tistory.com/92 [개발자로 홀로 서기]

위의 Book 예제에서 BooksProxy 가 addBooks 메서드를 수행하면, 아래와 같은 순서로 작동됩니다. BooksProxy::addBooks -> BooksImpl::addBooks → BooksImpl::addBook 즉, BooksImpl 내부의 코드(addBook) 가 Transaction 처리를 위한 프록시를 거치지 않고 바로 수행 되기 때문에 해당 메서드는 프록시로 감싸진 메서드가 아니라는 점에서 @Transactonal 어노테이션 기능이 수행되지 않는다.

• 격리 레벨 (isolation-level) : 다른 트랜잭션과의 동시 접속 방법을 제어

• ISOLATION_DEFAULT : DB의 기본 격리 수준 (기본값)

• ISOLATION_READ_UNCOMMITTED : 다른 트랜잭션이 아직 커밋하지 않은 수정 데이터를 볼수 있다. 트랜잭션 기능 거의 수행 안함.

• ISOLATION_READ_COMMITTED : 대부분 DB의 기본 수준. 다른 트랜잭션이 커밋하지 않은 데이터는 읽을 수 없다. 하지만 어떤 느랜잭션이 특정 데이터를 읽은 상태에서 다른 트랜잭션이 해당 데이터를 수정 가능

• ISOLATION_REPEATABLE_READ : 트랜잭션 내에서 일단 한 번 데이터를 읽어오면 다시 읽어올 때마다 동일한 데이터를 읽어온다. 한 트랜잭션이 읽은 데이터를 다른 트랜잭션이 수정할 수 없지만 새 데이터를 삽입할 수는 있으며, 새로 삽입된 데이터는 다른 트랜잭션에서도 읽을 수 있다.

• ISOLATION_SERIALIZABLE : 모든 트랜잭션은 하나씩 차례대로 실행되는 것처럼 처리. 가장 비용이 크로 신뢰할 수 있는 격리 수준.

• 트랜잭션 전파 옵션(propagation)

• PROPAGATION_REQUIRED : 이미 존재하는 트랜잭션을 지원하고, 트랜잭션이 없으면 새 트랜잭션 시작 (기본값)

• PROPAGATION_SUPPORTS : 이미 존재하는 트랜잭션을 지원하고, 트랜잭션이 없으면 비트랜잭션으로 실행

• PROPAGATION_MANDATORY : 이미 존재하는 트랜잭션을 지원하고, 진행 중인 트랜잭션이 없으면 예외를 던짐.

• PROPAGATION_REQUIRES_NEW : 항상 새로운 트랜잭션을 시작. 진행 중인 트랜잭션이 있다면 해당 트랜잭션은 일시적으로 중단됨.

• PROPAGATION_NOT_SUPPORTED : 진행 중인 트랜잭션과 함께 실행 불가. 항상 비트랜잭션으로 실행하고 기존 트랜잭션을 일시 중단

• PROPAGATION_NEVER : 진행 중인 트랜잭션이 있더라도 항상 비트랜잭션으로 실행된다. 진행 중인 트랜잭션이 있다면 예외를 던짐.

• PROPAGATION_NESTED : 진행 중인 트랜잭션이 있는 경우 중첩 트랜잭션으로 실행됩니다. 진행 중인 트랜잭션이 없으면PROPAGATION_REQUIRED로 설정됨.

• readOnly : 기본값 false. 현재 해당 그 트랜잭션 내에서 데이터를 읽기만 할건지 설정. 이걸 설정하면 DB 중에 read 락과 write 락을 따로 쓰는 경우 해당 트랜잭션에서 의도치 않게 데이터를 변경하는 일을 막아줌. 성능을 최적화하기 위해 사용할 수도 있고 특정 트랜잭션 작업 안에서 쓰기 작업이 일어나는 것을 의도적으로 방지하기 위해 사용할 수도 있다. 일반적으로 읽기 전용 트랜잭션이 시작된 이후 INSERT, UPDATE, DELETE 같은 쓰기 작업이 진행되면 예외가 발생한다.

• rollbackFor / noRollbackFor : 트랜잭션은 UnchekedException 발생시 기본으로 roll-back 처리함. 만약 체크 예외가 발생해도 롤백하고 싶으면 rollbackFor = IOException.class 와 같이 명시 반대로 Unchecked Exception이 발생해도 롤백을 안하고 싶으면 noRollbackFor = NullPointerException.class와 같이 명시

• timeout : (기본값은 별도 timeout이 없음 = -1) 지정한 시간 내에 해당 메소드 수행이 완료되이 않은 경우

1. 유저가 로그인을 시도 (http request)
2. AuthenticationFilter 에서부터 위와같이 user DB까지 타고 들어감
3. DB에 있는 유저라면 UserDetails 로 꺼내서 유저의 session 생성
4. spring security의 인메모리 세션저장소인 SecurityContextHolder 에 저장
5. 유저에게 session ID와 함께 응답을 내려줌
6. 이후 요청에서는 요청 쿠키에서 JSESSIONID를 까봐서 검증 후 유효하면 Authentication를 쥐어준다.

힌트란 SQL 튜닝의 핵심 부분으로 일종의 지시 구문이다.

즉, 오라클 옵티마이저(Optimizer)에게 SQL문 실행을 위한 데이터를 스캐닝하는 경로, 조인하는 방법 등을 알려주기 위해 SQL사용자가 SQL 구문에 작성하는 것을 뜻한다. 오라클이 항상 최적의 실행 경로를 만들어 내기는 불가능하기 때문에 직접 최적의 실행 경로를 작성해 주는 것이다. 사용자가 특정 SQL 문장에서 어떤 인덱스가 선택도가 높은지 알고 있는 경우 Optimizer에 의존한 실행 계획보다 훨씬 효율적인 실행 계획을 구사할 수 있다.단, 힌트, 인덱스, 조인의 개념을 정확히 알고 사용하지 않은 무분별한 힌트의 사용은 성능의 저하를 초래하기 때문에 잘 알고 최적의 실행 경로를 알고 있을 경우 적절하게 사용하여야 한다.

(힌트에 오타가 있는 경우는 큰 관계가 없다. 왜냐하면, 잘못 사용된 힌트는 무시되어 힌트가 없는 것처럼 동작하기 때문)

힌트를 사용하여 아래와 같은 것들을 할 수 있다.액세스 경로, 조인 순서, 병렬 및 직렬 처리, Optimizer의 목표(Goal)를 변경 가능하다.

데이터 값을 정렬해야 하는 경우, 힌트의 사용이 필요하다. 참고 링크👉🏻클릭

또한, 드라이빙 테이블을 원하는 대로 선정하고자 할 때도 사용된다. 참고 링크👉🏻 클릭

출처:

https://devuna.tistory.com/35

[튜나 개발일기📚]

Redis(Remote Dictionary Storage, 레디스)와 Memcached(맴캐시드)는 유명한 오픈소스인, 인메모리 데이터 저장소입니다. 둘 모두 사용하기 쉽고, 고성능을 자랑합니다. 하지만, 엔진으로 사용할 때 차이를 반드시 고려해야합니다. 맴캐쉬드는 명료하고 단순함을 위하여 개발된 반면, 레디스는 다양한 용도에 효과적으로 사용할 수 있도록 많은 특징을 가지고 개발되었습니다. 기본적으로 redis는 memcached의 단점을 보안하고자 만들어졌습니다. 각 엔진들이 제공하는 기능과 필요한 상황을 고려하면, 선택이 어렵지 않을 것 같습니다.

• redis와 memcached 모두 In-Memory 메모리 기반이다.
• key-value 형식의 No-sql이다.

1ms 이하의 응답시간을 제공합니다. 데이터를 메모리에 저장하기 때문에, 디스크 기반의 데이터베이스보다 빠르게 데이터를 읽을 수 있습니다.

문법적으로 사용하기 쉽고, 개발코드 양 또한 적습니다.

데이터를 여러 노드에 분산하여 저장시킬 수 있습니다. 따라서 수요가 증가할 때 더 많은 데이터를 효과적으로 처리하기 위하여 스케일아웃이 가능합니다.

여러 개발언어를 지원합니다. 자바, 파이썬, C, C++, C#, JavaScript, Node.Js, Ruby, Go 그리고 다른 언어들을 지원합니다.

• 자료구조가 다양합니다. String, Set, Sorted Set, Hash List 등 다양한 자료구조를 제공합니다.
• 현재는 JSON 타입에 대해서도 지원한다.
• 메모리 뿐만 아니라 디스크도 사용하기 때문에(스냅샷 기능) 데이터 복구시 유용하다.
• 싱글 스레드를 사용한다. Redis는 싱글 쓰레드이기 때문에, 1번에 1개의 명령어만 실행할 수 있습니다. Keys(저장된 모든키를 보여주는 명령어)나 flushall(모든 데이터 삭제)등의 명령어를 사용할 때, 맴캐쉬드의 경우 1ms정도 소요되지만, 레디스의 경우 100만건의 데이터 기준 1초로 엄청난 속도 차이가 있습니다.
• 다양한 Eviction 정책을 동에 세밀한 Eviction 제어가 가능하다

• 멀티스레드 아키텍처를 지원한다.
• Redis 보다 적은 메모리를 요구한다.
• Redis와 Memcached 사이에 기본적으로 데이터를 저장하고 캐싱하는 방식에 차이가 있는 것 같다. Memcached는 정적인 데이터 저장에 유리하다. Redis는 Copy-on-Write 방식을 사용하기 때문에 실제 사용하는 메모리보다 더 많은 메모리를 요구한다.

다수의 트랜잭션이 경쟁시 발생할 수 있는 문제

다수의 트랜잭션이 동시에 실행되는 상황에선 트랜잭션 처리방식을 좀 더 고려해야 한다.

예를들어 특정 트랜잭션이 처리중이고 아직 커밋되지 않았는데 다른 트랜잭션이 그 레코드에 접근한 경우 다음과 같은 문제가 발생할 수 있다.

▶ Problem1 - Dirty Read

• 트랜잭션 A가 어떤 값을 1에서 2로 변경하고 아직 커밋하지 않은 상황에서 트랜잭션B가 같은 값을 읽는 경우 트랜잭션 B는 2가 조회 된다.

• 트랜잭션 B가 2를 조회 한 후 혹시 A가 롤백된면 결국 트랜잭션B는 잘못된 값을 읽게 된 것이다. 즉, 아직 트랜잭션이 완료되지 않은 상황에서 데이터에 접근을 허용할 경우 발생할 수 있는 데이터 불일치이다.

▶ Problem2 - Non-Repeatable Read

• 트랜잭션 A가 어떤 값 1을 읽었다. 이후 A는 같은 쿼리를 또 실행할 예정인데, 그 사이에 트랜잭션 B가 값 1을 2로 바꾸고 커밋해버리면 A가 같은 쿼리 두번을 날리는 사이 두 쿼리의 결과가 다르게 되어 버린다.

• 즉, 한 트랜잭션에서 같은 쿼리를 두번 실행했을 때 발생할 수 있는 데이터 불일치이다.

Dirty Read에 비해서는 발생 확률이 적다.

▶ Problem3 - Phantom Read

• 트랜잭션 A가 어떤 조건을 사용하여 특정 범위의 값들[0,1,2,3,4]을 읽었다. 이후 A는 같은 쿼리를 실행할 예정인데, 그 사이에 트랜잭션 B가 같은 테이블에 값[5,6,7]을 추가해버리면 A가 같은 쿼리 두번을 날리는 사이 두 쿼리의 결과가 다르게 되어 버린다.

• 즉, 한 트랜잭션에서 일정 범위의 레코드를 두번 이상 읽을 때 발생하는 데이터 불일치이다.

• ISOLATION_DEFAULT : DB의 기본 격리 수준 (기본값)
• ISOLATION_READ_UNCOMMITTED : 다른 트랜잭션이 아직 커밋하지 않은 수정 데이터를 볼수 있다. 트랜잭션 기능 거의 수행 안함. → Dirty Read 발생 가능!
• ISOLATION_READ_COMMITTED : 대부분 DB의 기본 수준. 다른 트랜잭션이 커밋하지 않은 데이터는 읽을 수 없다. 하지만 어떤 느랜잭션이 특정 데이터를 읽은 상태에서 다른 트랜잭션이 해당 데이터를 수정 가능 → Dirty Read 방지.
• ISOLATION_REPEATABLE_READ : 트랜잭션 내에서 일단 한 번 데이터를 읽어오면 다시 읽어올 때마다 동일한 데이터를 읽어온다. 한 트랜잭션이 읽은 데이터를 다른 트랜잭션이 수정할 수 없지만 새 데이터를 삽입할 수는 있으며, 새로 삽입된 데이터는 다른 트랜잭션에서도 읽을 수 있다. Non-Repeatable Read 방지
• ISOLATION_SERIALIZABLE : 모든 트랜잭션은 하나씩 차례대로 실행되는 것처럼 처리. 가장 비용이 크로 신뢰할 수 있는 격리 수준. Phantom Read 방지