JAVA/Spring/JVM

1차캐시 쓰기지연 dirty checking(스냅샷을 사용해 변화하는 부분 감지, 자동으로 업데이트 쿼리 생성함) (@Transactional(readOnly = true) 시 스냅샷, dirty checking 하지 않음) Transactional 관련 이슈 sel

웹 서비스에 팔로우 기능을 개발하던 중 프로트 측에 요청을 받았다.요청은 팔로워 리스트에서 내가 팔로워를 팔루우하고 있는지에 대한 데이터를 추가 해달라는 요청이였다. 현재 나는 팔로우, 팔로워 리스트를 반환할 때 같은 DTO를 사용하여 정보를 보내주고 있었다. 하지만

제네릭에 대해 알아보기 위해 collection에 대해 알아보자. 컬렉션의 페키지를 살펴보면 아래와 같다. 컬렉션은 데이터의 집합, 그룹을 의미하며 배열과 비슷한 역할을 한다. 하지만 이 컬렉션은 배열의 단점을 보완할 수 있는 방법이다. 기존의 배열은 크기가 정해져

혼자 강의를 보면서 개발을 하다보면 다음과 같은 코드를 자주 볼 수 있다. 이 코드들이 람다식과 관련있다는 것은 알았지만 정확히 어떤 원리로 코드가 작성되고 동작하는지 알 수 없었다. 그래서 람다 표현식에 대해 자세히 알아보기 위해서 위 코드들이 어떤 원리로 작성되었

이 내용은 자바 웹 프로그래밍 next step 책을 공부하다 정리하면 좋은 내용인 것 같아 따로 작성하게 되었다.이 내용은 어떤 exception은 try-catch문으로 꼭 처리를 해줘야 하고 어떤 exception은 메소드뒤에 throws exception으로 처

List int[] List[] arr = new Arraylist[3]; arr[0] = new ArrayList(); arr[1] = new ArrayList(); arr[2] = new ArrayList(); int Map

개발을 하다 보면 입력값과 출력값, 그리고 수행하는 역할이 동일하지만 세부 동작이 조금씩 다른 기능을 만들어야 할 때가 종종 있다. 이런 상황에서는 인터페이스에 메서드를 선언하고, 실제 메서드의 동작은 각 구현체에서 다르게 구현하는 방식을 적용하게 된다.문제는 이 구현

Spring Batch에서 chunk지향 처리에는 크게 3단계로 ItemReader, ItemWriter, ItemProcessor가 있는데 그중 ItemReader이 한 종류인 FlatFileItemReader에 대해 살펴보자.들어가기에 앞서 이 블로그는 정확히 어

JVM(Java Virtual Machine)이 운영체제로부터 데이터를 저장할 메모리 공간을 할당받아 자바 애플리케이션을 실행한다. 이 글은 자바 애플리케이션을 실행할 때인 런타임시 데이텅 영역에 대해 정리했다.

개발을 하다보면 로깅과 같이 같은 코드가 각각의 메소드에 똑같이 필요로 하는 경우가 있다. 이럴 경우 코드의 중복성을 줄이고 같은 코드를 재사용하기 위해 따로 관리하여 실행하는 방법이다.간단히 설명하자면 Spring에는 프록시라는 객체는 안에 있는 Advisor를 참고

@Transactional를 사용하며 AOP의 주의할 점을 살펴보자.먼저 @Transactional이 어떻게 동작하는지 로그를 통해 간단히 살펴보자.위 코드를 다음의 로그와 함께 살펴보면 @Transactional로 대상을 가로챈 순간 트랜잭션을 생성한다. 그 후 데이

🏢 영속성 컨텍스트 (The Persistence Context) JPA가 엔티티를 관리하는 '거대한 작업실'이며, 내부적으로 다음 3개 구역을 나누어 사용합니다. 엔티티 저장소 (1차 캐시): 역할: 현재 트랜잭션에서 사용 중인 '진짜 객체'들이 담긴 바구니입니다.

프로그램 : 코드 덩어리프로세스 : 코드 덩어리를 실행하기 위해 컴퓨터 자원을 할당 받은 상태스레드는 프로세스 내에서 동시에 진행되는 작업의 갈래이자 실행 흐름의 단위이다.백엔드 관점에서 보면 개발자가 서버를 실행할 때 JVM이라는 하나의 프로세스가 시작된다. 이때 운

대상 - 힙 힙 메모리 구조 minor gc major gc