백엔드
-
[OS, Java] Zero Copy백엔드/Java 2024. 7. 31. 19:15
올해 4월달쯤에 간단하게 공부하다가 넘어간 것 같은데, 이번에 제대로 공부할 기회가 생겼다. Zero Copy는 CPU를 사용하지 않고, 디스크/메모리에 저장된 정보를 다른 메모리에 저장하는 방식으로 기존 전통적인 데이터 복사 방식보다 더 성능이 좋은 방식이다. * 이번 내용은 운영체제 이론, 소켓에 대해 알고 있어야한다. (소켓 관련 글) 1. Zero Copy 이전에 사용하는 방법 운영체제에서 사용자 - 커널 공간이 따로 나뉘어져 있는 그림을 많이 봤을 것이다. 코드를 동작할 때, 동작 원리를 깊숙히 들어가면 system call이 호출되는 형식이다. 데이터 복사도 마찬가지로 system call을 사용해서 유저 영역과 커널 영역을 넘나들게 된다. 데이터 복사에서 제일 많이 사용하는 곳은 여러가..
-
[Java] ReentrantLock백엔드/Java 2024. 7. 22. 16:39
몇 주 전에 가상 스레드를 공부하기로 했는데, 생각보다 공부할게 너무 많아서 잘못 건드렸다는 생각이 많이 든다. 포스팅을 적어도 2주에 한 번씩은 하자고 생각했는데, 2주는 무슨 거의 한 달이 된 상황... 그래서 야금야금 분할정복하듯이 키워드를 적어보려고 한다. * 운영체제에 있는 내용은 안다고 가정하고 글을 작성함* CAS 알고리즘에 대해 알고 있으면 좋다 (CAS 알고리즘 포스팅 글) 1. Synchornized자바의 락은 모니터 개념을 사용하고 있다. 모니터란 특정 순간에 하나의 스레드만 객체 인스턴스에 접근할 수 있는 뮤텍스라고 생각하면 된다. 예를 들어서 메서드에 synchronized를 적용하면 인스턴스 메서드에 락이 걸리고, synchronized(객체 인스턴스)를 적용하면 객체 인스턴스..
-
[Concurrency] Actor Model백엔드/Java 2024. 5. 7. 16:17
* 용어 통일을 위해 Actor, 액터 혼용 대신 Actor로만 사용했습니다. 1. 서론동시성 프로그래밍 마지막 포스팅으로 Actor 모델이다. 지금까지 내용을 정리하면 다음과 같다.Compare and Swap(CAS)단일 값에 대해 원자성을 보장해준다. 하지만 "단일 값"만이다.Software Transactional Memory(STM)트랜잭션을 진행하는 동안 다른 메모리 공간에서 공유 자원에 대한 연산을 수행한 뒤 커밋하거나 롤백하여 적용한다. Actor 모델이 대두된 시기는 역시 STM과 똑같이 멀티코어 프로그래밍으로 인해 화두가 되었다. 다만 STM과는 다르게 처음 Actor 모델을 제안한건 1973년이고, 프로그래밍 언어로 만들어진건 1986년 Erlang 언어로 Actor 모델을 기반으로..
-
[Concurrency] Software Transactional Memory (Beautiful concurrency)백엔드/Java 2024. 4. 29. 15:11
1. 서론작년엔 동시성 문제에 synchronized, 비관적 락, 낙관적 락에 대해서만 알았다가 최근에 CAS 알고리즘에 대해 알게 되었다. 이걸 기점으로 Lock-Free에 대해 더 공부하고 있다가 STM을 발견했다. 이번에 중점적으로 참고한 내용은 2007년 마이크로소프트에서 Simon Peyton Jones라는 사람이 발표한 논문이다. 내용은 Haskell 언어를 통해 어떻게 효율적인 STM을 구현할 수 있는지에 대한 내용이다.(https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/beautiful.pdf) 검색해보니 STM이라는 개념은 90년대에 있었지만, 2005년부터 인텔과 암드 주도하에 싱글 프로세스에서 멀티 프로세스로 넘..
-
[Java, Concurrency] Compare and Swap 알고리즘 (CAS)백엔드/Java 2024. 4. 14. 07:46
HashMap과 ConcurrentHashMap 차이점에 대해 공부하다가 ConcurrentHashMap의 코드를 확인해보니 Segment는 Java 8 부터는 사용되지 않아 하위호환성을 위해 남겨둔 것을 발견했다. 그러면 어떻게 안전하게 동시성 처리를 하는지 확인해보니 synchronized, 버켓(노드) 락, CAS 알고리즘을 사용하는데, CAS 알고리즘은 처음 들어봐서 정리하게 됐다. 1. synchronizedCAS 알고리즘에 대해 설명하기 전에 먼저 synchronized에 대해 알고 있어야한다.자바의 락은 모니터 개념을 사용하고 있는데, 원하는 범위만큼 하나의 스레드만 락을 획득할 수 있는 방법이다. 인스턴스의 메서드에 synchronized를 적용하면 인스턴스 메서드에 락이 걸리고, syn..
-
[Spring, JPA] 50% 확률로 통과하는 LocalDateTime 테스트 코드 버그 수정하기백엔드/Spring 2024. 4. 4. 10:11
우테코 프로젝트에 슈뢰딩거의 테스트가 1개 있다. 운이 좋으면 50% 확률로 테스트에 성공하고, 운이 나쁘면 50% 확률로 테스트가 실패한다. 신기하게도 로컬에서는 단 한 번도 테스트가 실패한 적이 없었고, 서비스할 때도 전혀 문제 없었는데, Github Actions에서만 저렇게 빈번하게 실패한다. 1. 데이터 조회 방식 에러가 발생하는 곳은 최신순으로 정렬한 리뷰를 검증하는 테스트 코드에서 나오게 된다. 쿼리문이 길어서 where절만 가지고 왔다. 최신순으로 정렬한 리뷰는 다음 조건에 부합하는 데이터들을 가져오게 된다. 예시를 들어서 설명해보면, 만약 3번 상품에서 가장 마지막에 데이터로 보내준 리뷰가 6번 리뷰라고 가정해보자. 이때 최신순으로 정렬해서 보여줄 경우 다음 페이지는 6번 리뷰보다 더 일..
-
[JPA, MySQL] 같은 유저가 동시 접속을 해서 좋아요를 누르면 동시성 문제가..??백엔드/Spring 2023. 8. 15. 20:35
[리뷰 좋아요 트러블 슈팅] - 1편 : 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가..?? - 2편 : 같은 유저가 동시 접속해서 좋아요를 누르면 동시성 문제가..?? 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가 해결되어 문제를 해결한줄 알았습니다. 하지만 같은 유저가 500대의 전자기기에 동시 접속을 하여 동시에 좋아요를 누르면 이번엔 NonUniqueResultException이 발생하고 있었습니다. 😭 1개의 데이터만 들어가야 하는데, 10개의 데이터가 들어가서 에러가 발생합니다. MySQL에서도 확인해보니 똑같은 데이터가 10개나 들어있습니다. 1. 테스트 코드 작성하기 이번에는 ExecutorService를 사용해서 테스트를 만들었습니다. 이전에 여러명의 유저로 테스트하는..
-
[JPA, MySQL] 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가..??백엔드/Spring 2023. 8. 15. 14:39
[리뷰 좋아요 트러블 슈팅] - 1편 : 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가..?? - 2편 : 같은 유저가 동시 접속해서 좋아요를 누르면 동시성 문제가..?? 팀프로젝트에서 리뷰 좋아요 기능에 데드락과 동시성 문제가 발생했습니다. 어디서 데드락이 발생한지는 빠르게 파악했으나.. 근본적인 원인을 찾는데 오랜 시간이 걸렸습니다. 동시성 문제의 경우에는 500명이 리뷰 좋아요를 동시에 눌렀을 때, 좋아요 수가 500개가 아닌 50여개만 나오는 상황입니다. [발생 환경] MySQL 8.0.32 InnoDB [격리 수준] REPEATABLE_READ [데드락 발생 상황] 여러명의 유저가 좋아요 버튼을 전혀 눌러보지 않은 리뷰에서 동시에 좋아요를 누를 경우 발생 좋아요를 이미 눌렀던 리뷰라면 ..