
Thread 가시성이란 ? Thread 가시성이란 Thread의 시야 범위를 뜻한다. 공유하는 변수에 연산이 일어날 때 CPU를 점유하고 동작하는데 이 때 main memory에만 존재하는 것이 아니라 CPU cache에도 공유하는 자원에 대한 데이터가 들어있다. 이 때 CPU cache를 읽어오는데 언제 main memory에 옮겨갈 지 모르기 때문에 여러 thread가 동시에 읽음 연산과 쓰기 연산을 한다면 main memory에서 cache로 데이터를 옮기는 과정에서 다른 thread가 연산을 진행하여 결국 데이터 불일치 문제가 생기는 것이다. 이런 불일치 문제를 Thread 가시성 이슈라고 하며 자바에서는 volatile 키워드를 통해 해결할 수 있다. volatile은 캐시가 아닌 main me..

자세한 내용은 Github를 참고해주시기 바랍니다. 오늘은 레포지토리에 대해 얘기를 해보겠다. 레포지토리는 일단 설계부터 추상화를 이용해 구체화에 의존하지 않는 것이 핵심이라고 생각한다. 구체화에 의존하는게 왜? 객체지향을 공부했더라면 알 것이다. 구체화에 의존하는 것은 유지보수성을 떨어트린다. 우리가 알아야하는건 저장소이지 구체적으로 어떤 저장소인진 알아야할 이유가 전혀 없다. 오히려 그렇게 된다면 저장소가 바뀔 때마다 우리는 그에 맞춰 서비스도 바꿔주어야한다. 예를들어 우리는 QueryDSL을 이용하다가 갑자기 JOOQ로 넘어가야하는 상황을 가정해보자 그럴려면 우리는 JOOQ에 관련된 레포지토리를 만들고 그걸 서비스에 주입시켜줘야한다. 거기서 만약에 MyBatis까지 넣어준다면 MyBatis에 관련된..

프로젝트를 진행 중에 최근 데이터를 정렬하라는 요구사항에 대해 빠르게 성능을 올리고 싶어 여러가지를 찾아보던 중 커버링 인덱스라는 개념을 발견했다. 인덱스 ? 인덱스는 데이터를 효율적으로 탐색하는 방법이다. 하나의 색인같은 것으로 MySQL 미리 정렬된 상태의 하나의 클러스링된 테이블이 존재하면 이 테이블에 접근하여 빠르게 해당 아이디 값을 찾아가는 방식으로 동작한다. 이 때 성능이 매우 빠르기 때문에 DB 성능향상을 위해 꼭 필요한 기술이다. 커버링 인덱스? 커버링 인덱스 는 쿼리를 충족하는데 필요한 모든 데이터를 갖는 인덱스를 뜻한다.(SELECT/WHERE/GROUP BY/ ORDER BY) 아까 인덱스에서 잠시 언급한 미리 정렬된 상태의 클러스터링된 테이블에 접근하여 데이터를 인덱스 테이블에서 조..

Redis를 사용하던 와중 특정 오류가 잡혀 골치 아픈 적이 있었다. public class CacheConfig { private final RedisConnectionFactory redisConnectionFactory; @Bean public CacheManager cacheManager() { RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig() .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer())) .serializeValuesWith(Redi..

@Test @DisplayName("데이터베이스에 존재하는 게시판을 10개 조회해온다.") void findAll() { for (int i = 0; i < 10; i++) { Board board = Board.builder() .title(Title.from("테스트 용입니다. " + i)) .content(Content.from("테스트용 Content 입니다. 재미있다아앙")) .build(); boardService.create(board, 1L); } Pageable pageable = PageRequest.of(0, 10, Sort.Direction.DESC, "id"); List boards = boardService.findAll(pageable); assertThat(boards.siz..

대부분 제네릭에 대해 잘 알고 있다고 시작하는 포스팅이니 잘 모른다면 기본을 공부해보고 오는 것을 추천한다. https://blog.naver.com/ilgolc/222552815030 Java_Week14 Generics 란? 제네릭은 다양한 타입의 객체들을 다루는 메서드나 컬렉션 클래스에 컴파일 시의 타입 체크... blog.naver.com 제네릭 기초에 관한 내용들이 포스팅 되어 있으니 한 번 보고 이 글을 읽기를 바란다. 제네릭은 자바 5 부터 나온 문법으로 기본적으로 컬렉션에서 많이 볼 수 있었을 것이다. 제네릭은 다음 처럼 사용할 수 있다. List list = new ArrayList(); // 뒤에 선언 부에는 생략이 가능 그럼 바로 시작해보자. 로 타입 보다 Generic 제네릭을 사용..

1. MySQL 엔지 아키텍처 MySQL 전체구조 MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원한다. MySQL 고유의 C API부터 시작해 JDBC나 ODBC 등응 모든 언어로 MySQL 서버에서 쿼리를 사용할 수 있게 지원한다. MySQL서버는 크게 엔진과 스토리지 엔진으로 구분할 수 있다. 그러면 한 번 살펴보자. MySQL 엔진 MySQL 엔진은 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 sQL 파서 및 전처리기, 퀴리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다. 또한 MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다. 스토리지 엔진 ..

finally 블록 finally 블록은 보통 예외의 발생 여부와 상관없이 꼭 실행되어야 할 코드를 이 블록에 넣어 마지막에 출력하도록 처리한다. try { // 예외 처리가 발생할 가능성이 있는 로직 작성 } catch (Exception e) { // 예외 발생시 실행되는 로직 보통 에러 메시지를 출력 } finally { // 예외 발생 여부와는 상관없이 수행되는 로직 // finally 블럭은 try-catch문 마지막에 위치해야 함 } 예외 발생 시 try -> catch -> finally 순, 예외가 발생하지 않았을 땐 try -> finally 순으로 실행된다. 예제를 살펴보자 package exception; public class FinallyEx1 { public static void..
JPA를 왜 사용하는가? 필자는 블로그 프로젝트와 팀원들과 토이 프로젝트를 진행하며 JPA를 사용해 왔다. 과거에 JPA를 사용하면서 "SQL쿼리를 직접 작성하지 않는다"는 이점만 보고 JPA를 무작정 사용했던 것 같았다. 하지만 JPA는 우리가 생각하는 것 만큼 간단하지 않다. 복잡하지 않은 일반 개인 프로젝트에서는 무난히 사용했을 지 몰라도 복잡한 연관 관계를 갖고 있는 테이블이 있다고 가정해보자 우리는 이를 JPA로 간단하게 처리할 수 있는가? 그렇다면 JPA를 왜 사용하는지 JPA를 사용했을 때의 이점을 정확히 파악하고 우리는 그것을 남들에게 설명할 수 있어야 한다. 그 이유에 대해 먼저 알아보자 SQL을 직접 다룰 때 발생하는 문제점 RDBMS는 가장 대중적이고 신뢰할 만한 안전한 데이터 저장소..
- Total
- Today
- Yesterday
- lock
- Kotlin
- DB
- 게시판
- 취준
- 면접준비
- docker
- 프로그래밍
- Spring
- 코딩
- 백엔드
- 취업
- 코드
- 면접
- 개발자
- 면접 준비
- DevOps
- 프로젝트
- 인터뷰
- IT
- JPA
- 취업준비
- 동시성
- 개발
- 자바
- java
- thread
- CS
- MySQL
- Redis
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |