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

멀티스레드 & 스레드세이프티 & 스레드풀 각각의 특징을 설명하시오

• 스레드 : 프로세스(실행중인 프로그램)에서 하나의 실행 흐름.
• 멀티스레드 : 하나의 프로그램에서 여러 개의 실행 흐름을 만들고 실행 할 수 있다는 것이다.
• 스레드 세이프티 : 클래스나 함수, 객체등이 멀티쓰레드 환경에서 같은 데이터에 대해 동시 참여하여 예상치 못한 결과값을 얻게 되는 등의 side-effect 없이 정상적으로 동작을 보장하는 것을 의미한다.
• 스레드 풀 : 스레드가 생성될 때 OS가 요청을 받아들여 메모리 공간을 확보하고 메모리를 스레드에게 할당. 스레드는 동일한 메모리영역에서 생성되고 관리되지만, 생성 / 수거에 드는 비용을 무시할 수 없다. 따라서 요청이 들어올 때마다 스레드를 생성하고, 완료시 스레드를 수거하는 작업은 퍼포먼스에 지대한 영향을 줄 수 있다. 따라서 스레드를 이 풀에 미리 만들어놓는다.

또한 서비스 측면에서 바라볼때, 다수의 사용자의 요청을 빠르게 처리하고 대응하기 위해 스레드 풀을 사용한다.

애플리케이션에서는 사용자로부터 들어온 요청을 작업큐에 넣고, 스레드풀은 작업큐에 들어온 Task를 미리 생성해놓은 Thread들에게 할당한다. 일을 다 처리한 Thread는 결과값을 리턴한다.

• java의 스레드 풀 생성 / 사용 java.util.concurrent.Package에서 ExecuterService 인터페이스와 Executor 클래스를 제공 Executors 클래스의 다양한 정적 메소드를 통해 ExecutorService 구현 객체를 만들어서 사용할 수 있다. (스레드 풀 생성)
• java의 스레드 풀 종류
• newFixedThreadPool : 주어진 스레드 개수만큼 생성하고 그 수를 유지. 생성된 스레드 중 일부가 종료되었으면 스레드를 다시 생성.
• newCachedThreadPool : 처리할 스레드가 많아지면 그만큼 스레드를 증가(최대 스레드 개수 : Integer.MAX_VALUE)
• newSingleThreadExecutor : 스레드를 하나만 생성(1개로 계속 유지)
• newScheduledThreadPool : 특정 시간 이후, 또는 주기적 작업 스레드 사용시 활용

https://limkydev.tistory.com/55

Hashtable과 HashMap의 차이점은 무엇인가요?

공통점

• 둘다 맵의 순서를 보장하지 않음
• 둘다 key / value의 구조
• 객체들이 버켓에 전체적으로 고르게 분포되어 있다고 가정했을때 put 과 get 메소드들에 대해서 둘다 일정한 시간성능을 제공한다.
• 둘다 해실 원리에 기반하여 동작한다.

HashMap

• 멀티쓰레드 환경에서의 동기화 지원하지 않음 → ConcurrentHashMap 사용 권장

• 저장된 요소들의 순회를 위해 Fail-Fast-Iterator 사용 (ConcurrentHashMap은 Fail-Safe-Iterator 사용) Fail-Fast Iterator : 다른 스레드(에서 해당 자료에 요소를 수정(삽입, 삭제, 수정 등)이 발생하면 ConcurrentModificationException을 발생시켜 일관성을 보장한다.

  Fail-Safe-Iterator: ConcurrentHashMap의 경우 Map의 복사본을 참조하는 Iterator를 반환하며 다시 반환받은 시점에 Map에 수정이 있을 경우 해당 Iterator는 반영되지 않는다. 고로 ConcurrentModificationException또한 발생하지 않는다. 이는 약한 일관성(Weakly Consistent)를 제공하지만 다중 스레드상황에서 해당 Map의 무결성을 보장한다.

• 1개의 null키와 다수의 null값 사용 가능

HashTable

• 멀티쓰레드 환경에서 동기화 처리 가능 → 동기화 처리 비용 발생. 더 느림(모든 데이터 변경 메소드에 syncronized 키워드 사용되어 있음 → 매우 느린 동작)
• 저장된 요소들의 순회를 위해 Enumeration 사용 (컬렉션 프레임워크 이전에 사용되었던 인터페이스로 Iterator 사용을 권장한다.)
• key / value에 null값 사용 불가

객체의 직렬화와 역직렬화에 대해 설명하세요.

직렬화(Serialization)란?

• 말그대로 객체를 직렬화하여 전송 가능한 형태로 만드는 것을 의미한다. 객체들의 데이터를 연속적인 데이터로 변형하여 Stream을 통해 데이터를 읽도록 해준다.
• 이것은 주로 객체들을 통째로 파일로 저장하거나 전송하고 싶을 때 주로 사용된다.
• 자바 직렬화란 자바 시스템 내부에서 사용되는 객체 또는 데이터를 외부의 자바 시스템에서도 사용할 수 있도록 바이트(byte) 형태로 데이터 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 기술(역직렬화)을 아울러서 이야기합니다.
• 시스템적으로 이야기하자면 JVM(Java Virtual Machine 이하 JVM)의 메모리에 상주(힙 또는 스택)되어 있는 객체 데이터를 바이트 형태로 변환하는 기술과 직렬화된 바이트 형태의 데이터를 객체로 변환해서 JVM으로 상주시키는 형태를 같이 이야기합니다.

역직렬화(Deserialization)란?

• 직렬화된 파일 등을 역으로 직렬화하여 다시 객체의 형태로 만드는 것을 의미한다. 저장된 파일을 읽거나 전송된 스트림 데이터를 읽어 원래 객체의 형태로 복원한다.

자바 직렬화 조건

자바 기본(primitive) 타입과 java.io.Serializable 인터페이스를 상속받은 객체는 직렬화 할 수 있는 기본 조건을 가집니다.

역직렬화 조건

• 직렬화 대상이 된 객체의 클래스가 클래스 패스에 존재해야 하며 import 되어 있어야 합니다.

  • 중요한 점은 직렬화와 역직렬화를 진행하는 시스템이 서로 다를 수 있다는 것을 반드시 고려해야 합니다.(같은 시스템 내부이라도 소스 버전이 다를 수 있습니다. 이 부분은 다시 자세히 이야기하겠습니다.)

• 자바 직렬화 대상 객체는 동일한 serialVersionUID 를 가지고 있어야 합니다.

  private static final long serialVersionUID = 1L;

  자바 직렬화를 아시는 분은 위에서 기술한 예제에서 사용되는 자바 직렬화 대상의 Member 클래스가 serialVersionUID 상수가 없어서 의아하신 분도 계실 겁니다.사실 반드시 기술해야 되는 필수는 아니기 때문에 빼둔 것입니다. 하지만 상당히 중요한 부분이라서 따로 설명하려고 합니다. 이곳에서는 넘어가도록 하겠습니다.

자바 직렬화는 언제(when) 어디서(where) 사용되나요?

JVM의 메모리에서만 상주되어있는 객체 데이터를 그대로 영속화(Persistence)가 필요할 때 사용됩니다. 시스템이 종료되더라도 없어지지 않는 장점을 가지며 영속화된 데이터이기 때문에 네트워크로 전송도 가능합니다.그리고 필요할 때 직렬화된 객체 데이터를 가져와서 역직렬 화하여 객체를 바로 사용할 수 있게 됩니다.그런 특성을 살린 자바 직렬화는 많은 곳에서 이용됩니다. 많이 사용하는 부분 몇 개만 이야기해보겠습니다.

• 서블릿 세션 (Servlet Session)서블릿 기반의 WAS(톰캣, 웹로직 등)들은 대부분 세션의 자바 직렬화를 지원하고 있습니다.물론 단순히 세션을 서블릿 메모리 위에서 운용한다면 직렬화를 필요로 하지 않지만, 파일로 저장하거나 세션 클러스터링, DB를 저장하는 옵션 등을 선택하게 되면 세션 자체가 직렬화가 되어 저장되어 전달됩니다.(그래서 세션에 필요한 객체는 java.io.Serializable 인터페이스를 구현(implements) 해두는 것을 추천합니다.)참고로 위 내용은 서블릿 스펙에서는 직접 기술한 내용이 아니기 때문에 구현한 WAS 마다 동작은 달라질 수 있습니다.
• 캐시 (Cache)자바 시스템에서 퍼포먼스를 위해 캐시(Ehcache, Redis, Memcached, …) 라이브러리를 시스템을 많이 이용하게 됩니다.자바 시스템을 개발하다 보면 상당수의 클래스가 만들어지게 됩니다. 예를 들면 DB를 조회한 후 가져온 데이터 객체 같은 경우 실시간 형태로 요구하는 데이터가 아니라면 메모리, 외부 저장소, 파일 등을 저장소를 이용해서 데이터 객체를 저장한 후 동일한 요청이 오면 DB를 다시 요청하는 것이 아니라 저장된 객체를 찾아서 응답하게 하는 형태를 보통 캐시를 사용한다고 합니다.캐시를 이용하면 DB에 대한 리소스를 절약할 수 있기 때문에 많은 시스템에서 자주 활용됩니다. (사실 이렇게 간단하진 않습니다만 간단하게 설명했습니다.)이렇게 캐시 할 부분을 자바 직렬화된 데이터를 저장해서 사용됩니다. 물론 자바 직렬 화만 이용해서만 캐시를 저장하지 않지만 가장 간편하기 때문에 많이 사용됩니다.
• 자바 RMI(Remote Method Invocation)최근에는 많이 사용되지 않지만 자바 직렬화를 설명할 때는 빠지지 않고 이야기되는 기술이기 때문에 언급만 하고 넘어가려고 합니다.자바 RMI를 간단하게 이야기하자면 원격 시스템 간의 메시지 교환을 위해서 사용하는 자바에서 지원하는 기술입니다.보통은 원격의 시스템과의 통신을 위해서 IP와 포트를 이용해서 소켓통신을 해야 하지만 RMI는 그 부분을 추상화하여 원격에 있는 시스템의 메서드를 로컬 시스템의 메서드인 것처럼 호출할 수 있습니다.원격의 시스템의 메서드를 호출 시에 전달하는 메시지(보통 객체)를 자동으로 직렬화 시켜 사용됩니다.그리고 전달받은 원격 시스템에서는 메시지를 역직렬화를 통해 변환하여 사용됩니다.자세한 내용은 작은 책 한 권 정도의 양이 되기 때문에 따로 한번 찾아보시는 것을 추천드립니다.

자바 직렬화, 그것이 알고싶다. 훑어보기편 - 우아한형제들 기술 블로그

Spring 메시지 큐 Rabiit MQ vs KAFKA

RabbitMQ 와 Kafka 의 메인 목적은 분산 pub-sub 메세징 시스템이다.구독자들이 정확히 그들이 흥미있어하는 메세지를 읽을수있도록 해주고있다.그리고 그것의 분산시스템은 확장가능하며 신뢰성있게 해주고있다.

다양한 시스템과 연결되어 높은 신뢰성/확장성있는 엔터프라이즈 메세징 시스템이필요한곳이면 어디든 사용하고 있다.그러나 적제 적소에 사용하려면 위 두 솔루션을 비교해 볼 필요 가 있을듯 하다

RabbitMQ 와 Kafka

– RabbitMQ 가 좀더 성숙하다.– 철학은 좀 다른데, 기본적으로 RabbitMQ 는 브로커 중심적이며,생산자와 소비자간의 보장되는 메세지 전달에 촛점을 맞추었다.

– 반면 Kafka 는 생산자 중심적이며, 엄청난 이벤트 데이터을 파티셔닝하는데 기반을 둔다.배치 소비자를 지원하며, 온라인, 오프라인에 저 지연율(Low latency)을 보장하며 메세지를전달해 준다.

– RabbitMQ 는 브로커상에서 전달 상태를 확인하기위한 메세지 표식을 사용한다.카프카는 그런 메세지 표식이 없으며 컨슈머가 전달(배달) 상태를 기억하는것을 기대한다.

– RabbitMQ 는 커다란 크기의 데이터를 위해 디자인되지 않았으며만약 컨슈머가 매우 느리다면 실패할것이다.그러나 post 2.0 에 RabbitMQ 는 느린 배치 컨슈머를 핸들링 되는게 요청되어졌다.

– Kafka 은 오직 토픽같은 exchanges 를 사용한다.RabbitMQ 는 다양한 exchanges 를 사용한다. (토픽/큐 등)

– Kafka 는 파티션들 안에서 메세지 순서를 제공하며, 파티션들간에 엄격한 순서를 가진다.카프카 컨슈머들은 충분히 스마트해야하며 그들 스스로 파티션간의 순서를 해결(resolve) 해야한다.

– Kafka 는 디스크상에서 메세지를 저장하고 데이타 손실을 막기위해 클러스터로 그들을 복제한다.각각의 성능에 큰 문제없이 브로커는 테라바이트를 핸들링할수있다.Kafka 는 쓰기에 초당 200k 메세지를 읽는데는 3M 메세지를 제공되도록 되어었다.

Kafka – 초당 100k 이상의 불같은 이벤트를 처리 하려면 이용해라. – 온라인이나 배치로 파티션된 순서로 적어도 한번은 배달될 필요가있을때

– 메세지를 다시 읽을 필요가 있을때도 사용해라.또한 노드레벨 HA 로 흐름제한을 다룰수있을것이다.

RabbitMQ

– 초당 20+ 메세지를 복잡한 방식으로 컨슈머(worker)에게 라우트 하고 싶을때 사용하라.

– 메세지당 전달보장을 해줄필요가 있을때 사용하라.

– 배달 순서는 별로 관여치 않을때 사용하라.(순서를 보장하게 도 할수있다)

– 클러스터 노드레벨의 HA 가 필요할때 사용하라.

https://pegasuskim.wordpress.com/2016/05/13/apache-kafka와-rabbitmq-의-차이/#:~:text=– 철학은 좀 다른데%2C 기본적,파티셔닝하는데 기반을 둔다.

Spring의 Filter와 Interceptor의 차이점을 아는가?

• Filter와 Interceptor는 실행되는 시점이 다르다.
• Filter는 Web Application에 등록을 하고, Interceptor는 Spring의 Context에 등록을 한다.
• Filter는 Servlet에서 처리하기 전후를 다룰 수 있다. (서블릿 앞단에 위치)
• Interceptor는 Handler를 실행하기전(preHandle), Handler를 실행한 후(postHandle), view를 렌더링한 후(afterCompletion) 등, Servlet내에서도 메서드에 따라 실행 시점을 다르게 가져간다. (서블릿 뒤에 위치)

(Spring)Filter와 Interceptor의 차이

RDB의 데드락이 일어나는 상황과 교착상태에 대해서 설명하시오

교착상태(Dead Lock)란?

어떤 집합 내에 있는 모든 프로세스가 대기 상태이며 이 집합 내에 있는 각 프로세스가 이 집합 내에 다른 프로세스가 가지고 있는 자원을 기다리고 있으면 '교착상태' 라고 한다.

• 작업 T1은 리소스 R1 (R1에서 T1까지의 화살표로 표시)에 대한 잠금을 가지며 리소스 R2에 대한 잠금을 요청했다 (T1에서 R2 로의 화살표로 표시됨).
• 작업 T2는 자원 R2에 대한 잠금을 가지며 (R2에서 T2 로의 화살표로 표시됨) 자원 R1에 대한 잠금을 요청했다 (T2에서 R1 로의 화살표로 표시됨).
• 두 작업은 자원이 사용 가능할 때까지 계속 수행 할 수 없으며 Task가 계속 될 때까지 자원을 해제 할 수 없기 때에 교착 상태가 존재한다.

교착 상태의 조건

1. 상호배제(Mutual exclusion) : 프로세스들이 필요로 하는 자원에 대해 배타적인 통제권을 요구한다.
2. 점유대기(Hold and wait) : 프로세스가 할당된 자원을 가진 상태에서 다른 자원을 기다린다.
3. 비선점(No preemption) : 프로세스가 어떤 자원의 사용을 끝낼 때까지 그 자원을 뺏을 수 없다.
4. 순환대기(Circular wait) : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있다.

DB 옵티마이저에 대해 아는가?

###옵티마이저

• 사용자가 질의한 SQL 문에 대해 최적의 실행 방법을 결정하는 역할을 수행합니다.
• 이러한 최적의 실행 방법을 실행계획(Execution Plan)이라고 합니다.
• 옵티마이저가 최적의 실행을 결정하는 방식에 따라 규칙기반(RBO, Rule Based Optimizer)와 비용기반(CBO, Cost Based Optimizer) 방식이 있습니다.

규칙기반 옵티마이저

• 규칙(우선 순위)를 가지고 실행계획을 생성합니다.
• 규실행계획을 생성할 때 참조하는 정보에는 인덱스 유무, 연산자, 객체 등의 종류가 있습니다.
• ORACLE 의 규칙기반 옵티마이저 순위이며, 숫자가 낮을수록 우선순위가 높습니다.

1. Single row by rowid

2. Single row by clusterjoin

3. Single row by hash cluster key with unique or primary key

4. Single row by unique or primary key

5. Cluster join

6. Hash Cluster key

7. Indexed cluster key

8. Composite index

9. Single column index

10. Bounded range search on indexed columns

11. Unbounded range search on indexed columns

12. Sort merge join

13. MAX or MIN of indexed column

14. ORDER BY on indexed column

15. Full table scan

이 중 주요한 규칙에 대해서만 간락히 설명합니다.

1. ROWID 를 통해서 테이블에서 하나의 행을 액세스 하는 방식입니다.

2. 유일 인덱스를 통해서 하나의 행을 액세스 하는 방식입니다. 이 방식은 인덱스 접근 후 인덱스에 존재하는 ROWID 를 추출하여 행을 액세스합니다.

3. 복합 인덱스에 동등 조건으로 검색하는 경우입니다.

4. 단일 컬럼인덱스에 = 조건으로 검색하는 경우입니다.

5. 인덱스가 생성되어 있는 컬럼에 양쪽 범위를 한정하는 형태로 검색하는 방식입니다. BETWEEN 이나 LIKE 가 있습니다. LIKE 는 '문자열%' 형태인 경우입니다.

6. 인덱스가 생성되어 있는 컬럼에 한쪽 범위만 한정하는 형태로 검색하는 방식입니다.

7. 테이블 전체를 액세스하면서 조건절에 주어진 조건을 만족하는 행만을 결과로 출력합니다.

비용기반 옵티마이저

• SQL 문을 처리하는데 필요한 비용이 가장 적은 실행계획을 선택하는 방식입니다.
• 비용기반 옵티마이저는 비용을 예측하기 위해서 규칙기반 옵티마이저가 사용하지 않는 테이블, 인덱스, 컬럼등의 다양한 객체 통계정보와 시스템 통계정보를 이용합니다.
• 통계정보가 없는 경우 비효율적인 실행계획을 생성할 수 있으므로, 정확한 통계정보를 유지하는 것이 중요합니다.

대안 계획 생성기

• 동일한 결과를 생성하는 다양한 대안 계획을 생성하는 모듈입니다.
• 대안 계획 생성이 너무 많아지면 최적화를 수행하는 시간이 그만큼 오래 걸리기 때문에, 대부분의 상용 옵티마이저들은 대안 계획의 수를 제약하는 방법을 사용합니다.
• 이러한 현실적인 제약으로 인해 생성된 대안 계획들 중에서 최적의 대안 계획이 포함되지 않을 수도 있습니다.

비용 예측기

• 대안 계획 생성기에 의해서 생성된 대안 계획의 비용을 예측하는 모듈입니다.

실행계획

• SQL 에서 요구한 사항을 처리하기 위한 절차와 방법을 의미합니다.
• 실행계획 형태는 조인순서, 조인기법, 액세스 기법, 최적화 정보, 연산 등이 있습니다.
• 조인 기법은 두 개의 테이블을 조인할 때 사용할 수 있는 방법으로 NL, Hash, Sort Merge 등이 있습니다.
• 액세스 기법은 하나의 테이블에 액세스 할때 사용할 수 있는 방법으로, Table Access, Index Access 가 있습니다.
• 최적화 정보는 옵티마이저가 실행계획의 각 단계마다 예상되는 비용 사항을 표시한 것입니다.

https://mozi.tistory.com/220