JJ_blog

Mutex Mutual Exclusion의 합성어로 공유된 자원의 데이터나 임계영역(critical Section) 같은 곳에 스레드들의 서로 겹치지 않거나 하나의 프로세스나 스레드가 접근하는 것을 막는다. 동기화 대상이 1개 다른 스레드들은 뮤텍스의 lock을 가지기 위해 대기하고 락을 해제하는 스레드가 있을 때까지 접근하지 못한다. Key 기반으로 한 상호배제 기법이다. 다중 프로세스들의 공유 리소스에 접근을 조율하기 위해 동기화(Sync) 또는 락(Lock)을 사용 그림을 보면 쉽게 이해할 수 있다. 카운터에 있는 화장실 키를 누군가가 가지고 화장실을 이용 중인 경우 다른 사람은 해당 화장실을 이용할 수 없다. 하지만 이용을 마친 누군가가 Key를 카운터에 다시 가져다 놓으면 다른 사람들이 화장실을..

의존 관계 자동 주입 설정정보가 없어도 자동으로 스프링 빈을 등록해 준다. @Autowired 기능도 제공해 준다. 사용방법 □ Config파일에 @ComponentScan Annotation 붙이기 @Configuration @ComponentScan public class AutoAppConfig { } □ 스프링 빈에 등록할 클래스들에 @Component Annotation을 붙인다. @Component public class MemoryMemberRepository implements MemberRepository {} @Component public class RateDiscountPolicy implements DiscountPolicy {} @Component public class Memb..

□ 스프링 없는 DI 컨테이너로 구성된 경우 스프링 없는 순수한 DI 컨테이너인 AppConfig를 요청할 때마다 새로 생성한다. ex) 트래픽이 초당 100인 경우 초당 100개 객체가 생성되고 소멸된다. → 메모리 낭비가 심하다. 싱글톤 패턴으로 해결 가능 □ 싱글톤 컨테이너를 적용 후 싱글톤 패턴 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다. 객체 인스턴스를 2개 이상 생성하지 못하게 막아야 한다. □ 싱글톤 예제 코드 public class SingletonService { //1. static 영역에 객체를 딱 1개만 생성해둔다. private static final SingletonService instance = new SingletonSer..

□ 스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext는 스프링 컨테이너이다. ApplicationContext는 인터페이스이다. Annotation 기반의 자바 설정 클래스, 스프링 컨테이너는 XML을 기반으로 만들 수 있다. 스프링 컨테이너 생성 과정 □ 스프링 컨테이너 생성 new AnnotationConfigApplicationContext(AppConfig.class); 스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야 한다. 해당 사진에서는 AppConfig.class 구성 정보로 지정했다. □ 스프링 빈 등록 스..

SRP (Single Responsibility Principle) 단일 책임의 원칙 하나의 모듈이 하나의 책임을 가져야 한다. 모듈이 변경되는 이유가 한 가지여야 한다 장점 변경이 필요할 때 수정할 대상이 명확해진다. ORP (Open-Closed Principle) 개방 폐쇄 원칙 확장에 대해 열려있고 수정에 대해서는 닫혀있어야 한다는 원칙 확장에 대해 열려있다: 요구사항이 변경될 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있다. 수정에 닫혀 있다: 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하고나 변경할 수 있다. → 추상화에 의존하면 문제 해결 가능 ISP (Interface Segregation Principle) 인터페이스 분리 원칙 클라이언트의 목적과 용도에 적합한..

요구사항에 따른 코드 구현 및 설계도는 생략하였다. □ 문제점 코드 public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } 이런 코드의 경우 OrderServiceImpl 는 Interface인 OrderService 에 의존하고 있다. (설계된 의도) FixDiscountPolicy(), RateDiscountPolicy()를 직접적으로 객체를 생성하므로 두 클래스에도 의존을 하게된다. → DIP를..

중복 데이터를 피하기 위해서 데이터를 쪼개 여러 테이블로 나눠서 저장된 관계형 데이터베이스에서 분리된 데이터를 원하는 결과로 도출하기 위해 여러 테이블을 조합하기 위해 컬럼 기준으로 행을 합쳐주는 연산 □ JOIN 예시 SELECT ... FROM R, S WHERE R.A S.B; 다음과 같은 SELECT문은 릴레이션 R의 Attribute A와 릴레이션 S의 Attribute B를 비교연산자를 통해 조건을 만족하는 튜플들의 집합을 구한다. R.A S.B; 인 경우 R.A와 S.B는 주로 기본 키와 외래 키의 관계를 갖는다. 특징 - N개의 릴레이션을 연관시키기 위해서는 N-1개의 JOIN 조건이 필요하다. - JOIN 조건을 생략하거나 틀리게 표현한 경우 카티션 곱이 생성된다. 더보기 SELECT *..

데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 다른 튜플들과 구별할 수 있는 유일한 기준이 되는 Attribute(속성) 최악의 경우 모든 Attribute들을 사용하면 튜플을 고유하게 식별할 수 있는데 다음과 같은 이유로 최소한의 Attribute로 이루어진 키에 관심을 갖게 된다. 1. 불필요하게 중복되는 Attribute가 많아지면 데이터 저장 공간이 낭비되고, 쿼리 성능이 저하될 수 있다. 릴레이션 A 신용카드번호 이름 주민등록번호 주소 1 A XXXX-XXXX 서울특별시... 2 B YYYY-YYYY 인천광역시... 릴레이션 B 신용카드번호 이름 주민등록번호 주소 사용금액 1 A XXXX-XXXX 서울특별시... 1,000,000 2 B YYYY-YYYY 인천광역시... 60..

애플리케이션을 설치할 때, 앱스토어와 운영체제가 디바이스의 환경에 맞게 설치하는 설치 최적화 기술 필요한 만큼의 리소스만 다운로드하기에 적은 디스크 사용량, 빠른 다운로드를 제공 Slicing 여러 가지 디바이스와 운영체제를 위한 앱 번들의 variants(변형)을 생성 및 제공하는 과정 variants(변형)에는 각 디바이스와 운영체제가 필요로 하는 실행 가능한 아키텍처와 리소스가 담겨있다. 개발자가 앱스토어 커넥트에 풀버전의 앱 빌드를 업로드하게 되면 앱스토어는 자동적으로 variants를 생성하고 전달한다. 유저가 앱스토어에서 앱을 다운로드하게 되면, 유저의 디바이스와 운영체제 버전에 맞는 variants를 다운로드하게 된다. on-demand resource(ODR) 주문형 리소스는 이미지, 음원..

async는 함수가 비동기로 처리된다는 것을 의미한다. await은 마킹된 곳은 potential suspension point(잠재적 일시 중단 지점)로 지정된다. async로 선언한 함수가 완료될 때까지 일시 중지 되는 지점이다. □ 예시 func asyncTest() async throws -> String { try await Task.sleep(nanoseconds: 3_000_000_000) //3초 return "sleep 끝" } print("before task") Task{ let string: String = try await asyncTest() print(string) } print("after task") // 출력 // before task // after task // sle..