JAVA

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

Thread 클래스를 상속한 클래스의 객체를 활용

1. Thread class를 상속
2. run()을 오버라이딩하여 구현
3. start()로 run() 메소드를 호출

Runnable 인터페이스를 구현한 클래스의 객체를 활용

1. Runnable 인터페이스 구현
2. run()을 오버라이딩하여 구현
3. Thread(Runnable) 객체를 만들어 start()로 run() 메소드를 호출

쓰레드를 동기화하는 과정 synchronized를 이용해서 임계영역을 설정하는 방법

1. synchronized 함수를 만들어 사용한다. ex) public synchronized void 메소드(){} -> 문제점 : 함수 전체에 lock 이 걸린다. 함수에 synchronized를 걸면 그 함수가 포함된 해당 객체에 lock을 거는것과 같다.

2. synchronized block을 사용한다. ex) synchronized(this) { 동기화 필요한 부분 } -> 필요한 block에서만 락이 걸린다.

---

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

-> 일반적으로 hashcode를 이용하여 map이나 set에 저장된 값을 빠르게 불러오는데 값이 모두 같다면 의미가 없어지므로 원하는 객체를 찾을 수 업다.

hashCode() 두 객체가 같은 객체인지 확인하는 Method hashcode()메소드(정확히 말하면, Object클래스의 hashcode메소드)는 각 객체에 대응되는 고유한 정수값(int)을 리턴한다. 예외) String 의 hashcode는 같은 객체가 아니라 같은 문자열을 가지면 hashcode의 값이 같다.

equals() 두 객체의 내용이 같은지 확인하는 Method

일반적으로 hashcode 와 equals 는 오버라이딩 하기 전까지 Object 클래스에서 정의된 것을 사용한다. 따라서 클래스를 새로 정의하여 두 객체를 비교하는 hashcode 를 재정의 해주어 객체를 올바르게 비교할 수 있도록 해야한다.

자바의 hashcode 규약 equals(Object)메소드가 true이면 두 객체의 hashCode 값은 같아야 한다. equals(Object)메소드가 false이면 두 객체의 hashCode가 꼭 다를 필요는 없다. 하지만 서로 다른 hashCode 값이 나오면 해시 테이블(hash table)의 성능이 향상될 수 있다는 점은 이해하고 있어야 한다.

---

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

---

SPRING

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

• 스프링에서 트랜잭션 처리 방법

스프링에서는 트랜잭션 처리를 지원하는데 그중 어노테이션 방식으로 @Transactional을 선언하여 사용하는 방법이 일반적이며, 선언적 트랜잭션이라 부른다.

클래스, 메서드위에 @Transactional 이 추가되면, 이 클래스에 트랜잭션 기능이 적용된 프록시 객체가 생성된다.

이 프록시 객체는 @Transactional이 포함된 메소드가 호출 될 경우, PlatformTransactionManager를 사용하여 트랜잭션을 시작하고, 정상 여부에 따라 Commit 또는 Rollback 한다.

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

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

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

▶ 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가 같은 쿼리 두번을 날리는 사이 두 쿼리의 결과가 다르게 되어 버린다.

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

• 스프링 트랜잭션 속성

[ 1. isolation (격리수준) ]

• 트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준을 말한다.

▶ DEFAULT

기본 격리 수준(기본설정, DB의 Isolation Level을 따름)

▶ READ_UNCOMMITTED (level 0)

• 커밋되지 않는(트랜잭션 처리중인) 데이터에 대한 읽기를 허용

• 즉 어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 B라는 아직 완료되지 않은(Uncommitted 혹은 Dirty) 데이터 B를 읽을 수 있다.

• Problem1 - Dirty Read 발생 리 개발 환경에서는 해당 Transaction 레벨을 허용하지 않아 [ READ_COMMITTED와 SERIALIZABLE만이 적합한 트랜잭션 레벨입니다 ] 라는 오류가 발생한다. 다른 옵션들은 문제 발생하지 않음.

▶ READ_COMMITTED (level 1)

• 트랜잭션이 커밋 된 확정 데이터만 읽기 허용

• 어떠한 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 해당 데이터에 접근할 수 없다.

• Problem1 - Dirty Read 방지

▶ REPEATABLE_READ (level 2)

• 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정이 불가능하다.

• 선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신하거나 삭제가 불가능 하기때문에 같은 데이터를 두 번 쿼리했을 때 일관성 있는 결과를 리턴한다.

• Problem2 - Non-Repeatable Read 방지

▶ SERIALIZABLE (level 3)

• 데이터의 일관성 및 동시성을 위해 MVCC(Multi Version Concurrency Control)을 사용하지 않음

(MVCC는 다중 사용자 데이터베이스 성능을 위한 기술로 데이터 조회 시 LOCK을 사용하지 않고 데이터의 버전을 관리해 데이터의 일관성 및 동시성을 높이는 기술)

• 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능하다.

• Problem3 - Phantom Read 방지

  (※ 격리 수준이 올라갈 수록 성능 저하의 우려가 있음)

사용 예)

@Transactional(isolation=Isolation.DEFAULT) public void something (int a) { … }

[ 2. propagation (전파옵션) ]

트랜잭션 동작 도중 다른 트랜잭션을 호출(실행)하는 상황이에 선택할 수 있는 옵션이다.

@Transactional의 propagation 속성을 통해 피호출 트랜잭션의 입장에서는 호출한 쪽의 트랜잭션을 그대로 사용할 수도 있고, 새롭게 트랜잭션을 생성할 수도 있다.

▶ REQUIRED

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

▶ SUPPORTS

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

▶ REQUIRES_NEW

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

▶ MANDATORY

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

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

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

▶ REQUIRES_NEW

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

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

▶ NOT_SUPPORTED

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

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

▶ NEVER

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

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

▶ NESTED

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

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

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

중첩된 트랜잭션은 먼저 시작된 부모 트랜잭션의 커밋과 롤백에는 영향을 받지만 자신의 커밋과 롤백은 부모 트랝개션에게 영향을 주지 않는다.

1. 어떤 작업을 진행하는 중 로그는 꼭 DB에 저장해야 할 때

이 로그를 저장하는 작업이 실패한다고 메인 작업의 트랜잭션까지는 롤백되버린다면 특히 쇼핑몰에서 고객 주문작업 등의 경우 매출 하락까지도 발생할 수 있는 중요한 문제이다.

반대로 로그를 남긴 후 메인 작업에서 예외가 발생한다면 이때는 저장한 로그도 롤백 되어야 하는게 맞다.

이럴 때 로그 작업을 메인 트랜잭션에서 분리해서 중첩 트랜잭션으로 만들어 두면 유용하게 사용할 수 있다. 이렇게 때문에 더욱 더 Business 로직을 잘 짜줘야 할 것이다.

중첩 트랜잭션은 JDBC 3.0 스펙의 저장포인트(savepoint) (클릭시 자세한 내용링크) 를 지원하는 드라이버와 DataSourceTransactionManager 를 이용할 경우에 적용 가능하다.

[ 3. readOnly 속성 ]

• 트랜잭션을 읽기 전용으로 설정할 수 있다.

• 성능을 최적화하기 위해 사용할 수도 있고 특정 트랜잭션 작업 안에서 쓰기 작업이 일어나는 것을 의도적으로 방지하기 위해 사용할 수도 있다.

• 일부 트랜잭션 매니저의 경우 읽기전용 속성을 무시하고 쓰기 작업을 허용할 수도 있기 때문에 주의해야 한다.

• 일반적으로 읽기 전용 트랜잭션이 시작된 이후 INSERT, UPDATE, DELETE 같은 쓰기 작업이 진행되면 예외가 발생한다.

• aop/tx 스키마로 트랜잭션 선언을 할 때는 이름 패턴을 이용해 읽기 전용 속성으로 만드는 경우가 많다. 보통 get이나 find 같은 이름의 메소드를 모두 읽기전용으로 만들어 사용하면 편리하다.

• @Transactional 의 경우는 각 메소드에 일일이 읽기 전용 지정을 해줘야 한다.

  read-only 애트리뷰트 또는 readOnly 앨리먼트로 지정한다.

  true인 경우 insert, update, delete 실행 시 예외 발생, 기본 설정은 false

ex)

@Transactional(readOnly = true)

[ 4. 트랜잭션 롤백 예외

(rollback-for, rollbackFor, rollbackForClassName) ]

=

• 선언적 트랜잭션에서는 런타임 예외가 발생하면 롤백한다.

• 반면에 예외가 전혀 발생하지 않거나 체크 예외가 발생하면 커밋한다.

  체크 예외를 커밋 대상으로 삼은 이유는 체크 예외가 예외적인 상황에서 사용되기보다는 리턴 값을 대신해서 비즈니스적인 의미를 담은 결과를 돌려주는 용도로 많이 사용되기 때문이다.

• 스프링에서는 데이터 액세스 기술의 예외는 런타임 예외로 전환돼서 던져지므로 런타임 예외만 롤백 대상으로 삼은 것이다.

• 하지만 기본 동작방식을 바꿀 수도 있다.

ex ) 체크 예외지만 롤백 대상으로 삼아야 하는 것이 있다면 XML의 rolback-for 애트리뷰트나 애노테이션의 rollbackFor 또는 rollbackForClassName 앨리먼트를 이용해서 예외를 지정하면 된다.

rollback-for 나 rollbackForClassName 은 예외 이름을 넣으면 되고, rollbackFor 는 예외 클래스를 직접 넣는다.

• @Transactional 에서는 다음과 같이 클래스 이름 대신 클래스를 직접 사용해도 된다.

@Transactional(readOnly=true, rollbackFor=NoSuchMemberException.class)

▶ rollbackFor 속성

특정 예외가 발생 시 강제로 Rollback

설정 예: @Transactional(rollbackFor=Exception.class)

▶ noRollbackFor 속성

특정 예외의 발생 시 Rollback 처리되지 않음

설정 예: @Transactional(noRollbackFor=Exception.class)

[ 5. timeout 속성 ]

지정한 시간 내에 해당 메소드 수행이 완료되이 않은 경우 rollback 수행. -1일 경우 no timeout(Default=-1)

ex) @Transactional(timeout=10)

출처: https://goddaehee.tistory.com/167 [갓대희의 작은공간]

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

• 인증(Authentication) : 보호된 리소스에 접근한 대상에 대해 이 유저가 누구인지, 애플리케이션의 작업을 수행해도 되는 주체인지 확인하는 과정(ex. Form 기반 Login)

• 인가(Authorize) : 해당 리소스에 대해 접근 가능한 권한을 가지고 있는지 확인하는 과정(After Authentication, 인증 이후)

스프링 시큐리티란? (공부필요!!!) 스프링 시큐리티는 스프링 기반의 어플리케이션의 보안(인증과 권한)을 담당하는 프레임워크이다. 만약 스프링시큐리티를 사용하지 않았다면, 자체적으로 세션을 체크하고 redirect 등을 해야할 것이다. 스프링 시큐리티는 보안과 관련해서 체계적으로 많은 옵션들로 이를 지원해준다. spring security는 filter 기반으로 동작하기 때문에 spring MVC 와 분리되어 관리 및 동작한다. 참고로 security 3.2부터는 XML로 설정하지 않고도 자바 bean 설정으로 간단하게 설정할 수 있도록 지원한다.

자료참고 : 스프링 시큐리티 -> https://sjh836.tistory.com/165

---

Database / SQL

SQL의 HINT를 설명해주세요.

데이터베이스 쿼리에서 다양한 SQL 구현체들은 데이터베이스 엔진에 쿼리 실행 방법을 지시하는 SQL 표준의 추가분으로서 힌트(hint)를 사용한다. SQL 튜닝에서 많이 사용된다.

사용예시 -> SQL>SELECT /*+ hint 내용 */

힌트를 사용하여 액세스 경로, 조인 순서, 병렬 및 직렬 처리, Optimizer의 목표(Goal)를 변경 가능하다. 데이터 값을 정렬해야 하는 경우, 힌트의 사용이 필요하다. 또한, 드라이빙 테이블을 원하는 대로 선정하고자 할 때도 사용된다.

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

Redis(Remote Dictionary Storage, 레디스)와 Memcached(맴캐시드)는 유명한 오픈소스인, 인메모리 데이터 저장소이다. 맴캐쉬드는 명료하고 단순함을 위하여 개발된 반면, 레디스는 다양한 용도에 효과적으로 사용할 수 있도록 많은 특징을 가지고 개발되었다.

공통점

1. 1ms 이하의 응답대기시간 1ms 이하의 응답시간을 제공합니다. 데이터를 메모리에 저장하기 때문에, 디스크 기반의 데이터베이스보다 빠르게 데이터를 읽을 수 있습니다. 2.개발의 용이성 문법적으로 사용하기 쉽고, 개발코드 양 또한 적습니다.
2. 데이터 파티셔닝 데이터를 여러 노드에 분산하여 저장시킬 수 있습니다. 따라서 수요가 증가할 때 더 많은 데이터를 효과적으로 처리하기 위하여 스케일아웃이 가능합니다.
3. 다양한 프로그래밍 언어 지원 여러 개발언어를 지원합니다. 자바, 파이썬, C, C++, C#, JavaScript, Node.Js, Ruby, Go 그리고 다른 언어들을 지원합니다.

Memcached만 의 특징

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

Redis만 의 특징

1. 더욱 다양한 데이터 구조 문자열 뿐만 아니라 List, Set, 정렬된 Set, Hash, Bit 배열, hyperloglogs (매우 적은 메모리로 집합의 개수를 추정할 수 있는 방법)을 지원합니다. 프로그램에서 위의 다양한 자료구조를 사용할 수 있습니다. 예를 들어, Sorted Set을 활용하여 게임유저의 상위랭크 정보를 쉽게 제공할 수 있습니다.
2. Snapshots 레디스는 특정시점에 데이터를 디스크에 저장하여 파일 보관이 가능합니다. 또한, 장애상황시 복구에 사용할 수 있습니다.
3. 복제 Master — Salves 구조로, 여러개의 복제본을 만들 수 있습니다. 따라서 데이터베이스 읽기를 확장할 수 있기 때문에 높은 가용성(오랜 시간동안 고장나지 않음) 클러스터를 제공합니다
4. 트랜젝션 트렌젝션이란 데이터베이스 상태를 변경시키는 작업 단위를 의미하고, 원자성, 일관성, 독립성, 지속성의 특징을 가지고 있습니다. Redis는 이러한 특징을 지원합니다.
5. Pub / Sub messaging Publish(발행)과 Sub(구독)방식의 메시지를 패턴 검색이 가능합니다. 따라서 높은 성능을 요구하는 채팅, 실시간 스트리밍, SNS 피드 그리고 서버상호통신에 사용할 수 있습니다.
6. 루아 스크립트 지원 매우 경량화된 절차스크립트 언어인 루아를 지원합니다. eval 명령어를 사용하여 루아스크립트를 실행시킬 수 있습니다. 따라서, 프로그램을 명료하게하고 성능을 높일 수 있습니다.
7. 위치기반 데이터 타입 지원 Redis는 실시간 위치기반데이터를 지원합니다. 따라서, 두 위치의 거리를 찾거나, 사이에 있는 요소 찾기등의 작업을 수행할 수 있습니다. 이를 활용하여 맛집, 길찾기 그리고 지도기반의 고성능 서비스를 제공할 수 있습니다.

주의점 위의 특징만 보면, 모든 상황에서 Redis를 선택해야할 것 같습니다. 하지만, Redis는 싱글 쓰레드이기 때문에, 1번에 1개의 명령어만 실행할 수 있습니다. Keys(저장된 모든키를 보여주는 명령어)나 flushall(모든 데이터 삭제)등의 명령어를 사용할 때, 맴캐쉬드의 경우 1ms정도 소요되지만, 레디스의 경우 100만건의 데이터 기준 1초로 엄청난 속도 차이가 있습니다. 또한, RDB 작업(특정 간격마다 모든 데이터를 디스크에 저장)이 매우 오래걸립니다. AWS, 60기가 메모리 기준으로 10분이나 소요됩니다. Redis 장애에 원인의 대부분이 해당 기능 때문에 발생하기 때문에 사용할 때 주의해야합니다.

참고 : https://medium.com/@chrisjune_13837/redis-vs-memcached-10e796ddd717

추가 - Spring이 Redis를 선택한 이유 : https://deveric.tistory.com/65

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

트랜잭션 격리수준(isolation level)이란 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 것이다.

격리수준은 크게 아래의 4개로 나뉜다.

• READ UNCOMMITTED

각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관 없이 다른 트랜잭션에서 값을 읽을 수 있다. 정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장한다. DIRTY READ현상 발생 트랜잭션이 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있게 되는 현상

• READ COMMITTED

RDB에서 대부분 기본적으로 사용되고 있는 격리 수준이다. Dirty Read와 같은 현상은 발생하지 않는다. 실제 테이블 값을 가져오는 것이 아니라 Undo 영역에 백업된 레코드에서 값을 가져온다.

하나의 트랜잭션내에서 똑같은 SELECT 쿼리를 실행했을 때는 항상 같은 결과를 가져와야 하는 REPEATABLE READ의 정합성에 어긋난다. 이러한 문제는 주로 입금, 출금 처리가 진행되는 금전적인 처리에서 주로 발생한다. 데이터의 정합성은 깨지고, 버그는 찾기 어려워 진다.

• REPEATABLE READ

MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다. Undo 공간에 백업해두고 실제 레코드 값을 변경한다. 백업된 데이터는 불필요하다고 판단하는 시점에 주기적으로 삭제한다. Undo에 백업된 레코드가 많아지면 MySQL 서버의 처리 성능이 떨어질 수 있다. 이러한 변경방식은 MVCC(Multi Version Concurrency Control)라고 부른다.

PHANTOM READ 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상 이를 방지하기 위해서는 쓰기 잠금을 걸어야 한다.

• SERIALIZABLE

가장 단순한 격리 수준이지만 가장 엄격한 격리 수준 성능 측면에서는 동시 처리성능이 가장 낮다. SERIALIZABLE에서는 PHANTOM READ가 발생하지 않는다.하지만.. 데이터베이스에서 거의 사용되지 않는다.