동기적과 비동기적은 프로그램이 작업을 수행하는 방식을 설명하는 데 사용되는 개념이다.

 

동기적(Synchronous)
  • 순차적 진행 (한 작업 시작되면 다음 작업은 이전 작업이 완료될 때 까지 대기)
  • 스레드의 차단 (작업이 진행되는 동안 호출한 스레드는 작업이 완료될 때 까지 차단(blocked))
전형적으로 동기적 작업은 호출한 스레드가 작업의 결과를 기다려야할 때 사용된다.
(데이터베이스 쿼리, DB의 데이터를 읽거나 쓸 때 데이터베이스 쿼리가 완료될 때까지 해당 스레드가 대기)
비동기적(Asynchronous)
  • 별도의 스레드 or 다른 방식으로써 작업 분리 (비동기적 작업은 별도 스레드 또는 방식으로 작업을 분리하여 호출한 스레드의 차단 없이 진행됨)
  • 백그라운드에서의 실행 (작업이 백그라운드에서 실행되기 때문에 호출한 스레드는 작업이 완료될 때 까지 다른 작업을 계속할 수 있음)
 비동기적 작업은 보통 I/O 작업, 네트워크 요청과 같이 시간이 오래 걸리는 작업을 처리할 때 사용된다.

 

사용 예시
  • 동기적 작업, 전화를 걸고 상대방의 대답을 기다리는 것과 같음 (기다리는 동안 다른 작업이 불가)
  • 비동기적 작업, 이메일을 보내고 응답을 기다리지 않고 다른 작업을 수행 (기다리는 동안 다른 작업이 가능)

'Java > 개념 정리' 카테고리의 다른 글

스레드의 차단(blocked)  (0) 2024.05.16
var 키워드에 대하여  (0) 2024.02.28
JWT(Json Web Token)의 구조  (0) 2024.02.22
Heap 이란?  (1) 2023.10.22
연결리스트(LinkedList)  (0) 2023.10.21

스레드의 차단은 스레드가 작업이 완료될 때까지 다른 작업을 수행하지 못하고 기다리는 상태를 뜻함.

 

스레드 차단의 발생 상황
  1. I/O작업 : 파일을 읽거나 쓰거나, 네트워크를 통해 데이터를 전송하거나 받는 등의 작업을 수행할 때 발생
    (스레드는 데이터가 읽혀지거나 쓰여질 때까지 차단됨)

  2. 동기적인 작업 : 다른 스레드가 완료될 때까지 기다리는 경우
    (스레드 A가 스레드 B가 완료될 때까지 기다리는 상황이라면, 스레드 A는 스레드 B가 작업을 완료할 때까지 차단)
    스레드를 메서드로 빗대어 예시를 들어보자면 위와 같이 작성되었을 경우,
    A 메서드 시작 > A 메서드 차단 > B 메서드 시작 > B 메서드 종료 > A 메서드 종료가 된다.

  3. 락(Lock) 획득 : 스레드가 특정 락을 획독하기 위해 대기하는 경우
    (다른 스레드가 해당 락을 해제할 때까지 스레드는 차단 상태)

'Java > 개념 정리' 카테고리의 다른 글

동기적 메서드와 비동기적 메서드  (0) 2024.05.16
var 키워드에 대하여  (0) 2024.02.28
JWT(Json Web Token)의 구조  (0) 2024.02.22
Heap 이란?  (1) 2023.10.22
연결리스트(LinkedList)  (0) 2023.10.21
UUID란 ?

범용 고유 식별자라는 뜻으로 네트워크상에서 중복되지 않는 ID를 만들기 위한 표준 규약이다.

128비트 길이의 값으로 표현되는 식별자로, 전 세계적으로 고유하게 유지되도록 설계되었다.

 

UUID의 구성

UUID는 하이픈(-)으로 구분된 36자리의 16진수 숫자로 표현된다.

123e4567-e89b-12d3-a456-426655440000

 

UUID의 사용 용도
  • 데이터베이스의 레코드 식별자
  • 세션 식별자
  • 파일 이름
  • 객체 식별자
  • 소프트웨어 구성 요소 식별자
나는 S3에 사진을 저장할 때 이름의 중복을 피하고자 이용하게 됐다.

 

UUID의 장점
  • 고유성 : 전 세계적으로 고유한 값을 보장
  • 분산성 : 중앙 등록 기관 없이 생성이 가능
  • 무작위성 : 충돌 가능성이 매우 낮음
  • 간단성 : 생성 및 사용이 비교적 간단

UUID의 구성 깊게 보기

위와 같이 UUID는 5개의 필드로 구성된다.

  1. time_low (4바이트)
    - UUID가 생성된 시간의 하위 32비트
    - 16진수 표현
  2. time_mid (2바이트)
    - UUID가 생성된 시간의 중간 16비트
    - 16진수 표현
  3. time_hi_and_version (2바이트)
    - UUID가 생성된 시간의 상위 12비트와 UUID 버전을 나타냄
      - 상위 4비트는 UUID의 버전 (가장 많이 사용되는 것은 [1] 타임스탬프 기반과 [4] 랜덤 생성)
      - 하위 12비트는 시간의 상위 12비트
    - 16진수 표현
  4. clock_seq_hi_and_res (2바이트)
    - UUID를 생성한 시스템 클럭의 시퀀스 번호의 상위 3비트와 예약된 3비트
      - 상위 3비트는 시퀀스 번호의 상위 3비트
      - 하위 3비트는 예약된 비트
    - 16진수 표현
  5. node (6바이트)
    - UUID를 생성한 시스템의 고유 식별자
    - 48비트로 표현
    - MAC 주소와 같은 네트워크 어드레스로 생성되거나 임의로 생성 됨

UUID 레코드 레이아웃 예시

- 123e4567은 time_low 필드

- e89b는 time_mid 필드

- 12d3는 time_hi_and_version 필드

(상위 4비트 > 버전)
(하위 12비트 time_hi 필드)

- a456은 clock_seq_hi_and_res 필드

(상위 3비트 > 시퀀스 번호의 상위 3비트)
(하위 3비트 > 예약된 비트)
- 426655440000은 node 필드

 

Git이란
소프트웨어 개발에 있어 소스 코드의 변경 이력의 추척, 관리를 편리하게 할 수 있게 도와주는 수단
나 또는 협업을 하고 있는 다른 개발자가 코드를 작성하고 수정할 때 마다 변경사항을 저장한다. 이를 통해 손쉽게 이전의 상태로 되돌릴 수 있고, 여러명의 동시 개발에 있어 충돌도 방지할 수 있다.
Git의 핵심 개념
  • Repository (저장소)
    • Git이 코드 변경 사항을 저장하는 곳.
      로컬 저장소와 원격 저장소로 나뉜다. 
      로컬 저장소는 개발자 개인의 컴퓨터에, 원격 저장소는 여러 개발자가 공유하는 서버에 위치한다.
  • Commit (커밋)
    • 코드 변경 사항의 기록 단위.
      커밋은 코드 변경 사항에 대한 설명과 함께 저장되며 이를 통해 변경 이력을 추적할 수 있다.
  • Branch (브랜치)
    • 코드를 분리하여 독립적으로 작업할 수 있는 가상의 작업 공간.
      새로운 기능을 개발하거나 버그를 수정할 때 브랜치를 생성하여 작업하고, 작업이 완료되면 원래의 브랜치로 병합할 수 있다.
  • Merge (병합)
    • 두 개의 브랜치를 합치는 과정.
      작업이 완료되면 다른 브랜치의 변경 사항을 현재 브랜치에 통합하여 코드를 합친다.
  • Pull Request (풀 리퀘스트)
    • 코드 변경 사항을 다른 개발자에게 검토받고 통합하기 위한 요청.
      주로 오픈 소스 프로젝트나 팀 프로젝트에서 사용된다.

 

'Java > Git' 카테고리의 다른 글

main -> main (non-fast-forward) 처리  (0) 2024.02.27
  • refreshToken을 이용해 accessToken을 발행하는 로직을 구현 하던 도중..

서블릿에서의 에러가 발생

  • JwtAuthenticationFilter의 doFilterInternal 메서드 내부의 로직 때문에 생긴 에러이다.
    • doFilterInternal 로직 중 accessToken을 확인해 만료가 됐다면 refreshToken 메서드(서비스)로 연결이 된다.
    • 해당 서비스단 내부에서 새 토큰의 발행을 돕고, 그때 refreshToken 역시 만료가 됐다면 커스텀익셉션인 UserException을 발생시켜 GlobalExceptionHandler를 통해 처리가 되는 로직이다.
    • 그 과정에서 위의 문제가 발생했다.

문제가 발생하는 로직

  • 이유는 ?
    • 기존의 GlobalExceptionHandler로 처리 되던 에러들은 doFilterIntenal을 벗어나 로직상에서 문제가 발생 됐기에 처리가 가능했다.
    • 하지만 refreshToken 서비스는 doFilterIntenal 내부의 로직이기에 GlobalExceptionHandler로 연결 되지 못하고 예기치 못한 에러(서블릿단에서의 에러)로 연결 됐던 것

수정 후의 로직

  • try / catch를 이용해 서비스단에서 발생 시킨 UserException를 Filter 내부에서 직접 처리 해준다.
    • response를 새로 생성해 status 및 body를 생성해 내보낸다.
    • 마지막 return을 붙이지 않으면 지정해줬던 UserException이 아닌 403 Fobidden 상태를 발생시킨다.
      • return으로 현재의 로직 (response를 새로 만드는 것 까지) 을 끝내지 않으면 기존의 로직 (권한을 만들어내지 못한 상태로 진행) 이 진행 되어 결국 권한이 필요했던 요청에 권한이 없는 상태로 응답을 하기 때문에 UserException 을 발생시키지 않고 403 에러 메시지가 발생 되는 것.

 

나중에 내가 기억하기 위해 서비스단도 적어놓자.

'Java > Spring' 카테고리의 다른 글

[Security] JWT란 ?  (0) 2024.06.18
Redis Config 설정 (로컬환경에서의 설정 방법)  (0) 2024.06.17
RedisUtil (get, set 설정)  (0) 2024.04.16
RedisRepositoryConfig 설정  (0) 2024.04.16
PasswordEncoder 알고리즘 이모저모  (0) 2024.04.15

  • RedisTemplate<String, String> redisTemplage;
    • Redis와 통신하기 위한 Spring Date Redis의 Redis Template
  • setValues(key, value, duration)
    • redis에 저장될 키와 밸류 및 Duration 객체를 저장
  • getValues(key)
    • key를 통해 value를 가져옴

+ Recent posts