밍 끄적

공유 자원 여러 스레드가 동시에 접근할 수 있는 자원 임계 영역 공유 자원들 중 여러 스레드가 동시에 접근했을 때 경쟁 상태 문제가 생길 수 있는 영역 경쟁 상태 둘 이상의 스레드가 공유 자원을 동시에(병행적으로) 읽거나, 쓰는 동작을 수행할 때, 실행하거나 접근했을 때의 타이밍이나 접근 순서에 따라 실행 결과가 달라지는 문제 경쟁 상태 대표적으로 두가지의 패턴의 상황에서 발생한다. 패턴 1. Read - Modify - Write 아래 예제를 보면, cnt라는 변수의 값이 increase() 메소드를 통해 1씩 증가한다. 이 메소드를 100개의 요청이 동시에 수행된다면 우리가 기대하는 값은 100이다. public int cnt; public void increase(){ cnt++; } 하지만, 실제..

해싱 해시테이블에서도 사용하는 알고리즘이다. 주어진 키에, 해시 함수를 적용하고, 테이블의 총 크기/길이로 나눈 나머지 값을, 즉 modular(%)연산의 값으로 서버 인덱스를 가지는 개념이다. 로드밸런서로 라우팅 시에 아래와 같이 해싱을 통해 처리해줄 수 있다. Request ID 추출 : IP, User ID, 몇번째로 Request를 요청했는지에 대한 순서, … Hash(Request ID)를 통한 해시값 도출 주어진 해시값에 따라 라우팅 문제점 위와 같이 어떠한 갯수, 크기에 따라서 해시 처리를 하면, 갯수, 크기가 변하면 모든게 변하게 된다. 위 이미지에서는 총 크기를 5로 잡았는데, 만약 4로 변경하게 된다면 아래와 같이 많은 데이터가 다른 인덱스를 가져야한다. 이렇게 버킷이 추가되거나 삭제됨..

ConcurrentHashMap의 등장 배경 Map 인터페이스의 구현체로는 HashMap, HashTable, ConcurrentHashMap 등이 있다. Map 인터페이스를 구현하면, 형태를 띈다. 이 중, ConcurrentHashMap은 Java 1.5 버전에서 HashTable의 대안으로 처음 소개된 Collection이다. 이전까지는, 멀티 스레드 환경에서 Thread-safe하게 Map을 사용하려면, 해당하는 메소드 혹은 해당하는 코드 블럭을 Lock으로 감싸거나 HashTable을 사용하거나 SynchronizedMap을 사용하거나 해야했다. 하지만 위 방법에는 문제가 있다. HashTable, SynchronizedMap을 동기화 시키기 위해 락을 걸면, 특정 엔트리에만 락을 거는 것이 아..

2023.05.16 - [Java & Spring] - Filter 지난번에 정리한 Filter에 이어 Interceptor를 정리하였다. Interceptor Interceptor 인터셉터 Interceptor는 위의 이미지 처럼, Spring Context 영역에서 실행되는, Spring이 제공하는 기술이다. 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공한다. Filter 이후에, Spring Context 영역에서 실행되는 Dispatcher Servlet은 요청에 따른 컨트롤러를 매칭시키위해, 핸들러 매핑을 수행하고 HandlerExecutionChain을 리턴한다. FilterChain이 각 필터를 순서에 따라 다 거친 뒤에 서블릿을 호출한 것 처럼, Han..

Filter 필터 필터는 Dispatcher Servlet에 요청이 전달되기 전, 요청이 처리된 후에 url 패턴에 맞는 모든 요청에 대해 부가 작업을 처리할 수 있는 기능을 제공한다. 필터는 Web Context에서, 즉 톰캣과 같은 웹 컨테이너(서블릿 컨테이너)에서 관리가 된다. Dispatcher Servlet이 존재하는 Spring Context 즉 스프링 컨테이너에서 관리되지 않는다. 단, 스프링 빈으로 등록은 된다. 이유는 하단에서 다룬다. 필터는 아래와 같은 기능을 수행하기 좋다. 로그인여부나 권한 검사와 같은 인증 기능 요청이나 응답에 대한 로그(기록) 기능 오류 처리 기능 데이터 압축이나 변환 기능 인코딩 처리 기능 필터를 사용하려면, Filter 인터페이스를 구현해야한다. ( imple..

Default Method 자바8에서, 기존의 구현체를 깨뜨리지 않고, 비교적 안전하게 인터페이스에 메소드를 추가하는 방법 기존에는 메서드 하나를 추가하려면 해당 인터페이스를 구현하는 모든 클래스에서는 해당 메서드를 모두 구현해줘야 했다. 하지만, 디폴트 메서드를 이용하면 인터페이스의 기분 구현을 그대로 상속하므로 인터페이스에 자유롭게 새로운 메서드를 추가할 수 있게 된다. 호환성을 유지하면서 API를 바꿀 수 있는 것이다. java8의 java.util.Collection 인터페이스 java7의 Collection 인터페이스는 원래 removeIf 메소드가 없었다. Collection (Java Platform SE 7 ) Collection (Java Platform SE 7 ) Compares th..

아래의 이전 게시글에서, Spring AOP에 관한 기본 개념을 정리하였다. 이번 글은 Spring AOP 중 프록시 패턴을 적용한 경우와 프록시에 대해 정리하였다. Spring AOP - AOP 기본 Spring AOP - AOP 기본 개념 Spring AOP - 1편 AOP는 여러 오브젝트에 나타나는 공통적인 부가 기능을 모듈화하여 재사용하는 기법이다. SRP에 따르면, 클래스를 변경하는 이유은 하나다. 만약, 어떤 로그인 서비스의 수행시간을 magenta-ming.tistory.com 프록시 패턴을 통해 AOP 적용하기 프록시 패턴 ( 런타임 위빙 ) 런타임 시에 프록시를 통해 부가 기능이 적용되는 방식 구체적인 방식 스프링 애플리케이션 컨텍스트가 생성될 때, 타겟과 같은 인터페이스를 구현하는 프록..

상속은 캡슐화를 위반할 수 있다 캡슐화 : 객체의 상태와 행동을 하나의 단위로 묶고, 외부에는 상태를 감추고 행동만을 노출시키는 것 상속을 통해 메소드 재정의를 수행할 수 있는데, 이는 캡슐화를 해칠수 있다. 릴리스마다 내부 구현이 달라질 수 있는 상위 클래스로 인해 하위 클래스가 오동작 할 수 있기 때문이다. 따라서 이미 구현된 class의 상속을 지양하고, implement 상속을 사용하는 것이 좋다. 하위 클래스의 오작동 : self-use 패턴을 사용했을 때 자기 사용 self-use : 자신의 다른 부분을 사용하는 것 / 한 메소드가 같은 클래스 내의 다른 메서드를 사용하는 패턴 public class InstrumentedHashSet extends HashSet { private int ad..

Spring AOP - 1편 AOP는 여러 오브젝트에 나타나는 공통적인 부가 기능을 모듈화하여 재사용하는 기법이다. SRP에 따르면, 클래스를 변경하는 이유은 하나다. 만약, 어떤 로그인 서비스의 수행시간을 측정하기 위해 측정 로직은 서비스 내에 넣는다면, 서비스 로직 말고 부가 기능이 비즈니스 로직을 위한 서비스 코드에 포함된다. 맞는 접근일까? 수행시간을 측정하고, 트랜잭션을 처리하고, 권한을 체크하는 등의 부가 기능 작업은 모두 일종의 인프라 로직이다. 인프라 로직 어플리케이션의 전 영역에서 나타날 수 있다. 중복 코드를 만들어낼 가능성 때문에 유지보수가 힘들어진다. 비즈니스 로직과 섞여 있으면, 비즈니스 로직을 이해하기가 어려워진다. 인프라 로직은 각자의 관심사가 있다. 인프라 로직의 중복이 횡단..

아래는 우리가 알고 있는 일반적인 생성자의 형태이다. public class Person { public Person() { } } Static Factory Method 이번 세션의 아이템 1에서 제안하는 방식은 정적 팩터리 메소드 ( Static Factory Method ) 를 이용하여 아래와 같은 형태로 선언하는 것이다. public class Person { private static Person PERSON = new Person(); private Person() { // 외부 생성 금지 } public static final Person getInstance() { // factory method return PERSON; } } static으로 선언된 메서드 new Object()와 같이..