JAVA

자바에서 쓰레드를 구현하는 방법과 동기화되는 과정을 설명하시오.

Thread를 구현하는 방법으로는 2가지 방법이 있습니다.

1. Thread 클래스를 상속 받습니다

• Thread 클래스를 상속 받을 시에는 다른 클래스를 상속 받을 수 없습니다.

2. Runnable 인터페이스를 구현합니다.

• Runnable 인터페이스를 구현하는 클래스를 만듭니다. 이 클래스의 객체는 Runnable 객체가 됩니다.
• Thread 타입의 객체를 만들 때, Thread의 생성자에 Runnable 객체를 인자로 넘깁니다. 이 Thread 객체는 이제 run() 메소드를 구현하는 Runnable 객체를 소유하게 됩니다.
• 이전 단계에서 생성한 Thread객체의 start() 메소드를 호출합니다.

hashCode() 값이 모두 같다면 어떤 일이 벌어지나요? hashcode()와 equls()는 언제 사용하고 왜 사용하는지?

• equals()는 두 객체의 내용이 같은지, 동등성(equality)를 비교하는 연산자입니다.
• hashCode()는 두 객체가 같은 객체인지, 동일성(identity)를 비교하는 연산자입니다.
• equals()로 비교 시 두개의 오브젝트가 같다면, hashCode() 값도 같아야 합니다.
• equals()로 비교 시 false 라면, hashCode()값은 다를수도, 같을수도 있습니다. 그러나 성능을 위해서는 hashCode() 값이 다른 것이 낫습니다. 그래야 해싱 알고리즘으로 Set 에 해당 오브젝트가 존재하는지 아닌지 빠르게 검색 할 수 있습니다.
• hashCode() 값이 같다고 해서, equals()가 true를 리턴하는 것은 아닙니다. 해싱 알고리즘 자체의 문제로, 같은 해시 값이 나올 수 있습니다.

패러럴GC, G1GC의 차이점 설명해주세요

• Parallel GC(-XX:+UseParallelGC)

Parallel GC는 객체가 제일 먼저 생성되는 Young 영역과 데이터가 가득차면 실행하는 부분인 Old 영역이 있습니다. Young 영역에서는 Eden 영역과 Survivor 영역(2개)인 총 3가지 영역으로 구성되어있고, 각 영역의 처리 절차를 순서에 따라 기술하면 다음과 같습니다.

1. 새로 생성한 대부분의 객체는 Eden 영역에 위치한다.
2. Eden 영역에서 GC가 한 번 발생한 후 살아남은 객체는 Survivor 영역 중 하나로 이동된다.
3. Eden 영역에서 GC가 발생하면 이미 살아남은 객체가 존재하는 Survivor 영역으로 객체가 계속 쌓인다.
4. 하나의 Survivor 영역이 가득 차게 되면 그 중에서 살아남은 객체를 다른 Survivor 영역으로 이동한다. 그리고 가득 찬 Survivor 영역은 아무 데이터도 없는 상태로 된다.
5. 이 과정을 반복하다가 계속해서 살아남아 있는 객체는 Old 영역으로 이동하게 된다.

이후 Old 영역에서의 GC는 mark-sweep-compact이라는 알고리즘을 사용합니다. 이 알고리즘의 첫 단계는 Old 영역에 살아 있는 객체를 식별(Mark)하는 것입니다. 그 다음에는 힙(Heap)의 앞부분부터 확인하여 살아 있는 것만 남깁니다(Sweep). 마지막 단계에서는 각 객체들이 연속되게 쌓이도록 힙의 가장 앞 부분부터 채워서 객체가 존재하는 부분과 객체가 없는 부분으로 나뉩니다(Compaction). GC를 처리하는 쓰레드가 여러개여서 빠르지만 메모리를 많이 차지하기 때문에 메모리가 충분하고 코어의 개수가 많을 때 유리합니다. Parallel GC는 Throughput GC라고도 부릅니다.

• G1 GC

G1 GC는 Young 영역과 Old 영역으로 나누는 방식을 사용하지 않는 특이한 컬렉터입니다. 위의 그림과 같이 바둑판 모양으로 구성되어 있으며 약 2000개의 구역을 사용합니다. 이 바둑판 모양의 구역에서 일부를 선정하여 Young 영역으로 지정한 후 해당 구역에 데이터가 꽉 차면 GC를 진행 합니다. GC 후 살아있는 객체만 Servivor 영역으로 이동합니다.

SPRING

Spring의 AOP의 특징과 어드바이스 종류와 사용된 proxy 패턴에 대해 설명해보세요.

스프링 AOP 특징

• 프록시 패턴 기반의 AOP 구현체, 프록시 객체를 쓰는 이유는 접근 제어 및 부가기능을 추가하기 위해서입니다.
• 스프링 빈에만 AOP를 적용 가능
• 모든 AOP 기능을 제공하는 것이 아닌 스프링 IoC와 연동하여 엔터프라이즈 애플리케이션에서 가장 흔한 문제(중복코드, 프록시 클래스 작성의 번거로움, 객체들 간 관계 복잡도 증가 ...)에 대한 해결책을 지원하는 것이 목적

Advice 종류

• @Before : 대상 객체의 메서드 호출 전에 공통 기능을 실행하는 데 사용됨.

• @AfterReturning : 대상 객체의 메서드가 익셉션 없이 실행된 이후에 공통 기능을 실행하는 데 사용됨.

• @AfterThrowing : 대상 객체의 메서드를 실행하는 도중 익셉션이 발생한 경우에 공통 기능을 실행하는 데 사용됨.

• @After : 종료 후에 무조건 실행됨. 대상 객체의 메서드를 실행하는 도중에 익셉션이 발생했는지의 여부에 상관없이 메서드 실행 후 공통 기능을 실행함. ( try-catch-finally의 finally블록과 비슷 )

• @Around : 대상 객체의 메서드 실행 전, 후 또는 익셉션 발생 시점에 공통 기능을 실행하는 데 사용됨. 캐시 기능, 성능 모니터링 기능과 같은 Aspect를 구현할 때 주로 이용

JDK Dynamic Proxy

JDK Dynamic Proxy는 JDK 1.3+ 부터 제공되는 Proxy Factory에 의해 런타임 시 동적으로 만들어 지는 오브젝트입니다. JDK Dynamic Proxy는 반드시 Interface가 정의 되어있고, Interface에 대한 명세를 기준으로 Proxy를 생성합니다. 따라서 Interface 선언에 대한 강제성이 있다는 단점이 있습니다. 내부적으로 Dynamic Proxy에서는 InvocationHandler라는 Interface를 구현하여 만들어지는데 InvocationHandler의 invoke라는 함수를 Override하여 Proxy의 위임 기능을 수행합니다. 이 과정에서 Object에 대해 Reflection기능을 사용하여 기능을 구현하기 때문에 퍼포먼스의 하락의 원인이 되기도 합니다.

CGLIB Proxy

CGLIB Proxy는 순수 Java JDK 라이브러리를 이용하는 것이 아닌 CGLIB라는 외부 라이브러리를 추가해야만 사용할 수 있습니다. 실제 CGLIB의 Enhancer라는 클래스를 바탕으로 Proxy를 생성하며, JDK Dynamic Proxy의 단점인 Interface가 없어도 Proxy를 생성 할 수 있습니다. CGLIB Proxy는 Target Class를 상속받아 생성됩니다. 그렇기 때문에 개발자는 Proxy를 생성 하기 위해 굳이 Interface를 만들어야 하는 수고를 덜 수 있습니다.

하지만, 상속을 이용하는 만큼 final이나 private과 같이 상속에 대해 Override를 지원하지 않는 경우 Proxy에서 해당 메소드에 대한 Aspect를 적용할 수 없다는 단점이 있습니다.

CGLIB Proxy의 경우 실제 바이트 코드를 조작하여 JDK Dynamic Proxy보다는 퍼포먼스가 상대적으로 빠른 장점이 있습니다.

스프링에서 @Transactional은 어떻게 동작하며 어떤 옵션이 있는가?

스프링에서는 트랜잭션 처리를 지원하는데 그 중 어노테이션 방식으로 @Transactional을 선언하여 사용하는 방법이 일반적이며, 선언적 트랜잭션이라 부릅니다. 클래스, 메소드 위에 @Transactional이 추가되면, 이 클래스에 트랜잭션 기능이 적용된 프록시 객체가 생성됩니다. 이 프록시 객체는 @Transactional이 포함된 메소드가 호출 될 경우, PlatformTransactionManager를 사용하여 트랜잭션을 시작하고, 정상 여부에 따라 Commit 또는 Rollback 합니다.

@Transactional의 Propagation 속성

▶ REQUIRED

• 디폴트 속성, 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 새로운 트랜잭션을 생성한다.

▶ SUPPORTS

• 이미 시작된 트랜잭션이 있으면 참여하고 그렇지 않으면 트랜잭션 없이 진행하게 만든다.

▶ REQUIRES_NEW

• 부모 트랜잭션을 무시하고 무조건 새로운 트랜잭션이 생성

▶ MANDATORY

• REQUIRED와 비슷하게 이미 시작된 트랜잭션이 있으면 참여한다.

• 반면에 트랜잭션이 시작된 것이 없으면 새로 시작하는 대신 예외를 발생시킨다.

• 혼자서는 독립적으로 트랜잭션을 진행하면 안 되는 경우에 사용한다.

▶ REQUIRES_NEW

• 항상 새로운 트랜잭션을 시작한다.

• 이미 진행 중인 트랜잭션이 있으면 트랜잭션을 잠시 보류시킨다.

▶ NOT_SUPPORTED

• 트랜잭션을 사용하지 않게 한다.

• 이미 진행 중인 트랜잭션이 있으면 보류시킨다.

▶ NEVER

• 트랜잭션을 사용하지 않도록 강제한다.

• 이미 진행 중인 트랜잭션도 존재하면 안된다 있다면 예외를 발생시킨다.

▶ NESTED

• 이미 진행중인 트랜잭션이 있으면 중첩 트랜잭션을 시작한다.

• 중첩 트랜잭션은 트랜잭션 안에 다시 트랜잭션을 만드는 것이다.

• 하지만 독립적인 트랜잭션을 만드는 REQUIRES_NEW와는 다르다.

스프링에서 인증과 인가를 처리하는 방식에 대해 설명해보세요.

인증 : 사용자의 정당성 확인 인가 : 사용자의 리소스 접근에 대한 제어

인증 처리 방식

Spring Security가 제공하는 인증 메카니즘

1. AuthenticationFilter

• 인증 처리 방식
• 클라이언트의 요청 파라미터에서 인증정보(계정, 패스워드)를 받고 Authentication Manager의 method 호출

2. AuthenticationManager(implementation : ProviderManager)

• 인증 처리를 수행하기 위한 인터페이스
• 기본 구현 : AuthenticationProvider에게 인증 처리를 위임하고 인증 결과를 받는 구조

3. AuthenticationProvider(implementation : DaoAuthenticationProvider)

• 인증 처리 기능을 구현하기 위한 인터페이스

인가 처리

사용자가 접근할 수 있는 resource 제어 resource에 대한 접근 정책 정의, resource 접근 시 접근 정책 확인 후 허용 여부 결정

1. ExceptionTranslationFilter

• 인가 과정에서 발생한 예외 처리
• 클라이언트에 응답을 하기 위한 servlet filter
• 인증되지 않은 사용자 접근 시, 로그인 페이지로 리다이렉트

2. FilterSecurityInterceptor

• HTTP 요청에 대한 인가 처리를 적용하기 위한 servlet filter
• AccessDecisionManager의 method를 호출하여 인가 처리

3. AccessDecisionManager(implementation : AffirmativeBased)

• AccessDecisionVoter의 method를 호출하여 접근 가능 여부 투표
• 하나의 AccessDecisionVoter가 부여로 투표하면 접근 권한 부여

4. AccessDecisionVoter(implementation : WebExpressionVoter)

• 접근하려는 resource에 접근 정책을 참조하여 접근 권한 부여 여부 투표

DATABASE/SQL

SQL의 HINT를 설명해주세요.

힌트는 SQL 튜닝의 핵심부분으로 일종의 지시구문입니다. SQL에 포함되어 쓰여져 Optimizer의 실행 계획을 원하는 대로 바꿀 수 있게 해줍니다. 오라클 Optimizer라고 해서 항상 최선의 실행 계획을 수립할 수는 없으므로 테이블이나 인덱스의 잘못된 실행 계획을 개발자가 직접 바꿀 수 있도록 도와주는 것입니다. 사용자는 특정 SQL 문장에서 어떤 인덱스가 선택도가 높은지에 대해 알고 있는데 이 경우 오라클 서버의 Optimizer에 의존하여 나온 실행 계획보다 훨씬 효율적인 실행 계획을 사용자가 구사할 수 있습니다.

memcached보다 redis의 공통점과 차이점은?

공통점

1. 1ms 이하의 응답대기시간

데이터를 메모리에 저장하기 때문에, 디스크 기반의 데이터베이스보다 빠르게 데이터를 읽을 수 있습니다.

1. 개발의 용이성

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

1. 데이터 파티셔닝

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

1. 다양한 프로그래밍 언어 지원

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

Memcached만의 특징

멀티스레드를 지원하기 때문에, 멀티프로세스코어를 사용 할 수 있습니다. 따라서, 스케일업을 통하여 더욱 많은 작업처리를 할 수 있습니다.

Redis만의 특징

1. 더욱 다양한 데이터 구조

문자열 뿐만 아니라 List, Set, 정렬된 Set, Hash, Bit 배열, hyperloglogs (매우 적은 메모리로 집합의 개수를 추정할 수 있는 방법)을 지원합니다. 프로그램에서 위의 다양한 자료구조를 사용할 수 있습니다. 예를 들어, Sorted Set을 활용하여 게임유저의 상위랭크 정보를 쉽게 제공할 수 있습니다.

2. Snapshots

레디스는 특정시점에 데이터를 디스크에 저장하여 파일 보관이 가능합니다. 또한, 장애상황시 복구에 사용할 수 있습니다.

3. 복제

Master — Salves 구조로, 여러개의 복제본을 만들 수 있습니다. 따라서 데이터베이스 읽기를 확장할 수 있기 때문에 높은 가용성(오랜 시간동안 고장나지 않음) 클러스터를 제공합니다

3. 트랜젝션

트렌젝션이란 데이터베이스 상태를 변경시키는 작업 단위를 의미하고, 원자성, 일관성, 독립성, 지속성의 특징을 가지고 있습니다. Redis는 이러한 특징을 지원합니다.

4. Pub / Sub messaging

Publish(발행)과 Sub(구독)방식의 메시지를 패턴 검색이 가능합니다. 따라서 높은 성능을 요구하는 채팅, 실시간 스트리밍, SNS 피드 그리고 서버상호통신에 사용할 수 있습니다.

5. 루아 스크립트 지원

매우 경량화된 절차스크립트 언어인 루아를 지원합니다. eval 명령어를 사용하여 루아스크립트를 실행시킬 수 있습니다. 따라서, 프로그램을 명료하게하고 성능을 높일 수 있습니다.

6. 위치기반 데이터 타입 지원

Redis는 실시간 위치기반데이터를 지원합니다. 따라서, 두 위치의 거리를 찾거나, 사이에 있는 요소 찾기등의 작업을 수행할 수 있습니다. 이를 활용하여 맛집, 길찾기 그리고 지도기반의 고성능 서비스를 제공할 수 있습니다.

트랜잭션 격리 수준 (Isolation Level) 에 대해서 설명하세요.

트랜잭션이 보장해야 하는 ACID 중 I에 해당되는 격리성(Isolation)을 보장하기 위해 모든 트랜잭션을 순차적으로 실행한다면 동시성 처리 이슈가 발생하며 반대로 동시성을 높이기 위해 여러 트랜잭션을 병렬처리하게 되면 데이터의 무결성이 깨질 수 있습니다.

위와 같은 문제들 때문에 ANSI표준에서 트랜잭션의 격리성과 동시 처리 성능 사이의 Trade-off를 두고 4단계 격리 수준을 나누었습니다. 내려갈수록 격리 수준이 높아져서 언급된 이슈는 적게 발생하지만 동시 처리 성능은 떨어집니다.

1. Read Uncommitted

한 트랜잭션에서 커밋하지 않은 데이터에 다른 트랜잭션이 접근 가능하다. 즉, 커밋하지 않은 데이터를 읽을 수 있다.

2. Read Committed

커밋이 완료된 데이타만 읽을 수 있다.

3. Repeatable Read

트랜잭션 내에서 한번 조회한 데이타를 반복해서 조회해도 같은 데이타가 조회 된다

이는 개별 데이타 이슈인 Dirty Read나 Non-Repeatable Read는 발생하지 않지만, 결과 집합 자체가 달라지는 Phantom Read는 발생가능하다.

4. Serializable

가장 엄격한 격리 수준

위 3가지 문제점을 모두 커버 가능하다. 하지만 동시 처리 성능은 급격히 떨어질 수 있다.