나의 개발일지

기존엔 Redis를 직접 실행해서 띄웠는데 번거로워서 docker에 Redis를 설치해놓고 실행시키기로 했다. 오랜만에 프로젝트를 띄우니 오류가 났다. 빌드를 다시 해주고 Redis Server를 일단 콘솔로 킨 다음에 회원가입, 로그인 부분을 진행해보았는데 아래와 같은 오류가 났다. * Trouble Shooting JWT strings must contaiob exactly 2 period characters. Found:0 더보기 2024-03-31 21:12:11.268 ERROR 18684 --- [io-8080-exec-10] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in c..

지난 번 포스팅에서 Redissson Client와 Embedded Redis를 기본 설정 해봤다. 이번엔 이것들을 바탕으로 현재 만들고 있는 프로젝트의 계좌에 Lock을 걸어서 동시성 이슈가 발생하지 않게 한다. 동시성 이슈란 ? 동일한 자원에 대해 둘 이상의 스레드가 동시에 제어할 때 나타나는 문제. 지역 변수에 대해서는 스레드마다 다른 메모리 영역을 할당 받기 때문에 발생하지 않지만 인스턴스 필드 또는 static과 같은 공용 필드에 접근에 대해서 발생한다. 동시성 문제란 동일한 자원에 대해서 접근한다고 무조건 발생하는 것이 아닌⇒ 즉, 변경하지 않고 읽기만 하면 발생하지 않음. 동시에 접근한 자원에 대해서 변경이 일어나는 경우 발생하는 문제 진행 과정 1. 커스텀 어노테이션 AccountLock을..

스프링 부트 스타터 레디스에는 Lettuce 라이브러리를 사용 (Spring-Boot-Starter-Redis) Lettuce는 Netty 기반의 비동기 방식으로 Jedis보다 사용이 권장됨. 그러나 스핀락 방식을 활용하고 있기 때문에 락 만료시간에 대한 정책이 필요하다.(순회 횟수 제한, 시간으로 제한 etc...) 스핀락 방식 : 계속해서 Lock을 획득하기 위해 순회하는 방식. 만약 lock을 획득한 스레드나 프로세스가 lock을 정상적으로 해제해주지 못 한다면 다른 스레드에서는 계속 lock을 획득하기 위해 시도하느라 실행되는 애플리케이션에 장애가 될 수 있음. => 이를 위해 락 만료시간에 대한 정책이 필요 + 또한 Lock을 획득하기 위해 순회하는 동안 계속해서 레디스에 요청을 보내게 되는데 ..

사용자가 프로그램을 실행하면 OS는 디스크에 저장된 데이터를 메모리로 로드한다. 하지만 메모리 공간은 한정되어 있고, 사용자는 동시에 많은 프로그램을 실행하고 싶어 한다. 이런 메모리 공간의 한계를 극복하기 위해 가상메모리라는 개념이 등장했다. 1.5.1 가상 메모리 가상 메모리는 프로세스의 일부만 메모리에 로드하고, 나머지는 디스크에 둔 상태로 프로세스를 실행하는 방식이다. 이 방식은 프로세스 전체가 메모리에 올라오지 않아도 프로세스를 실행하는데 문제가 없다는 점에서 착안했다. ㅅㅏ용자에게는 프로세스 전체가 메모리에 로드된 것처럼 보이지만, 실제로는 전체가 로드된 것이 아니어서 가상 메모리라고 한다. 다음 그림과 같이 프로세스 일부를 로드하고, 프로세스의 나머지 영역은 디스크에 두면 더 많은 프로세스를..

다수의 프로세스를 실행하려면 한정된 메모리 공간에 많은 프로세스를 로드할 수 있어야 한다. 그래서 메모리 공간을 더 효율적으로 활용하기 위한 여러 방안이 고안되었다. 연속 메모리 할당, 페이징, 세그먼테이션 등의 작동 방식과 장단점을 이해하고 있어야 이후의 가상 메모리를 더 쉽게 이해할 수 있다. 1.4.1 논리 메모리와 물리 메모리 CPU가 프로세스를 처리할 때 보는 주소 값과 실제 메모리의 주소 값은 다르다. 프로세스가 보는 메모리 영역 논리 메모리 영역(logical memory address space) / 가상 메모리 영역(virtual memory) 실제로 사용되는 메모리 영역 물리 메모리 영역 CPU가 프로세스를 실행하며 보는 주소 값 : 논리주소 / 가상주소 실제 메모리에서 사용되는 주소 ..