전체 글

github.com/minyun02 myun02302@gmail.com
·TIL
Soft Delete vs Hard Deletesoft delete(논리 삭제)실제 데이터를 삭제하는게 아니라 삭제용 칼럼을 두고 그 값을 변경해서 논리적으로 삭제를 구현하는 방식이다주로 isDeleted와 같은 boolean 필드를 만들거나 삭제 날짜 필드를 사용한다장점데이터 복구에 용이하다삭제된 데이터 이력을 유지할 수 있다관련 데이터의 참조 무결성을 유지하기 쉽다실수로 영구적 데이터 손실을 방지할 수 있다단점데이터베이스 크기가 계속 커진다인덱스 효율이 떨어질 수 있다실제 삭제를 위한 추가 작업이 필요할 수 있다hard delete(물리 삭제)실제 데이터를 테이블에서 삭제하는 방식이다장점데이터베이스 크기를 효율적으로 관리할 수 있다쿼리가 단순하고 직관적이다일반적으로 데이터베이스 성능이 더 좋다단점삭제..
·TIL
개인 프로젝트에서 엔티티 간의 관계를 다루면서 지연 로딩과 프록시를 조금 더 이해할 수 있는 순간을 경험했다. 프로젝에는 Match 엔티티는 inviter라는 Team 엔티티와 관계를 맺고 있다. 이 관계는 지연 로딩으로 설정되어 있다. 매칭을 수락하는 로직이 있는데 여기서 매칭을 보내온 inviter의 현재 상태를 확인해야 했는데, 여기서 생각과 다른 상황이 발생했다. matchValidator.validateTeamStatus(match.getInviter().getStatus());  위 코드가 그 상황이다. 지연 로딩을 사용할 때 조회되지 않은 엔티티는 프록시 객체 상태라는 개념은 알고는 있었다. 그리고 해당 엔티티가 필요한 순간에 조회 쿼리가 나간다는 사실도 알고 있었다. 그렇지만 정확히 어떤 ..
·TIL
Mocking실제 객체의 행동을 모방하는 가짜 객체를 만드는 과정이다객체의 동작을 검증할 대 사용한다행동 기반 테스트에 사용된다Stubbing특정 메서드 호출에 대해 미리 정의된 값을 반환하도록 설정하는 과정이다상태 기반 테스트에 사용된다사용 예시def "검색 조건이 있는 경우"() { given: def matchRepository = Mock(MatchRepository) // Mocking def matchService = new MatchService(matchRepository) def teamId = 1L def matchSearchDTO = new MatchSearchDTO() and: // Stubbing matchRepository.findAllMat..
·TIL
CopyOnWriteArrayList스레드 세이프 한 ArrayList읽기 작업이 많고 쓰기 작업이 적은 상황에서 사용하기 적합하다쓰기 작업 시 새로운 복사본을 생성하여 동시 읽기 작업과의 충돌을 방지한다대량의 쓰기 작업 시 성능에 영향이 생길 수 있다어떻게 동시성을 해결할까?불변성 사용쓰기 작업(추가, 삭제, 수정)이 발생하면 기존 배열의 복사본을 만든다이를 통해 읽기 작업은 항상 일관된 상태의 데이터를 참조할 수 있다동기화된 쓰기쓰기 작업은 synchronized 블록으로 감싸져 있다동시에 하나의 스레드만이 쓰기 작업을 수행한다ArrayList는 동시성 문제가 발생하면 어떤 일이 생길까?데이터 불일치한 스레드가 요소를 추가하는 동안 다른 스레드가 요소를 읽거나 삭제하려 하면 예상치 못한 결과가 나올 ..
·TIL
임계영역(Critical Section)여러 스레드가 공유하는 자원에 접근하는 코드 영역을 말하는 논리 영역이다멀티 스레딩 환경에서 여러 스레드가 동시에 접근할 때 문제가 발생할 수 있는 영역이다이 영역에서는 공유 자원에 대한 접근이 이루어지기 때문에 동시에 접근하면 데이터 불일치 문제가 발생할 수 있다공유 자원의 예로는 전역 변수, 파일, 데이터베이스 등이 있다임계영역 특징상호 배제 (Mutual Exclusion)한 스레드가 임계영역에서 실행 중일 때, 다른 스레드는 해당 임계영역에 진입할 수 없어야 한다한정된 대기 (Bounded Waiting)스레드가 임계영역 진입하기 위해 대기하는 시간은 한정되어야 한다즉, 무한정 대기하는 상황이 발생하면 안 된다진행 가능성임계영역에 진입하려는 스레드가 없다면,..
·TIL
동기화 문제데이터 경쟁 (Race Condition)두 개 이상의 스레드가 공유 자원에 동시에 접근하면서 값을 읽고 쓰면 경쟁이 발생하고 데이터 일관성이 깨질 수 있다데드락두 개 이상의 스레드가 서로 다른 자원을 기다리면 무한 대기 상태에 빠지는 현상이다라이브락스레드들이 서로의 진행을 방해하지 않기 위해 지속적으로 상태를 변경하지만 실제로 아무런 작업도 진행되지 않는 상태이다기아 (Starvation)특정 스레드가 자원을 획득하지 못하고 무한 대기 상태에 빠지는 현상이다자원 관리 문제과도한 컨텍스트 스위칭스레드가 너무 많이 생성되면 많은 컨텍스트 스위칭으로 오버헤드가 증가하고 성능이 저하된다메모리 누수스레드가 종료되지 않고 계속해서 실행 중이거나, 스레드가 사용한 자원이 적절하게 해제되지 않으면 메모리 ..
·TIL
ConcurrentHashMap동시성에 최적화된 해시맵 구현체여러 스레드가 동시에 데이터를 읽고 쓸 수 있도록 설계되어 있다동시성 최적화 방식세그먼트 락킹Java8 이전해시맵이 여러 세그먼트로 나누어져 각 세그먼트마다 개별적인 락을 사용했다하나의 세그먼트에서만 락이 걸려도 다른 세그먼트에 대한 접근이 여전히 가능했다Java8세그먼트 락킹 대신 세분화된 락으로 변경했다내부적으로 락 스트라이핑 기법을 사용하여 개별 버킷에 락을 걸지 않고, 필요한 경우에만 부분적으로 락을 사용한다락 프리 읽기 (Lock-free Reads)읽기 작업에는 락을 걸지 않고 진행한다이는 데이터 일관성을 유지하면서도 높은 읽기 성능을 제공한다읽기 작업이 수행될 때는 데이터 구조의 내부 상태가 변하지 않도록 보장하는 기술을 사용한다동..
·TIL
프로세스와 스레드의 차이점프로세스실행 중인 프로그램의 인스턴스를 말한다독립된 메모리 공간(코드, 데이터, 힙, 스택)을 가지고 있고 운영 체제에서 독립적으로 관리한다[[메모리 영역]]프로세스 간 메모리 접근이 원칙적으로는 불가능해서 다른 프로세스의 메모리를 침범할 위험이 없다그럼 침범하지 않는다는 원칙은 깰 수 있나?특정 상황이나 방법을 통해서 다른 프로세스의 메모리에 접근할 수 있다..!운영 체제를 이용한 방법운영 체제는 일부 메모리 영역을 여러 프로세스가 공유할 수 있도록 허용한다주로 [[프로세스 간 통신(IPC)]]을 위해서 사용하고 이 경우 프로세스는 특별히 할당된 공유 메모리 영역에 접근할 수 있다이 경우는 하나의 프로세스가 다른 프로세스의 메모리를 침범하는 경우가 아니라 공통된 영역에 접근하는..
삼공비
물음표&느낌표