안녕하세요. 강사님제가 이해하고 있는 게 맞는지 궁금하여 질문드립니다.자바 코드에서 두 개의 스레드를 생성하여 실행될 때의아래 메커니즘이 맞을까요..?↓ ↓ ↓1. thread.start를 두 번 하여 시스템 콜 호출 후 커널 영역에 커널 스레드 2개 생성 후 사용자 스레드와 맵핑-> 1 코어 하드웨어 스레드 1개가 OS 스케줄러에 의해 2개의 커널 스레드를 반복 선택하여 실행(매핑된 사용자 스레드같이 반복)(이 부분에서 자바 스레드는 기본적으로 동시성 방식으로 작동하고 작업을 병렬 방식으로 처리를 해야지 N 개의 코어를 사용하여 동시 처리되는 건가요?)--------------------------------------------------2. 커널 스레드는 사용자 스레드의 존재를 모르고 프로세스의 존재만 알고 있으며 PCB 정보를 가지고 있기 때문에 커널 스레드 TCB에 사용자 스레드 컨텍스 정보들을 저장하여 게속 스위칭을 반복하며 처리

안녕하세요! 네임드락 사용 시 락 선점 시간 설정에 있어 궁금한 부분이 생겨 질문 드립니다. Named Lock 활용해보기 강의 25초 부분에 "선점 시간이 끝나야 락이 해제된다" 고 언급해주셨는데, 이 선점 시간을 어떻게 설정하는지 궁금합니다. "get_lock" 명령어에 주는 파라미터는 해당 lock 을 획득하기 위해 대기하는 시간의 최대값으로 알고 있습니다. 그래서 hikariCp 에서 얻어온 커넥션을 점유할 수 있는 최대 시간 설정 값도 찾아봤는데 찾지 못했습니다.별도의 타이머를 구현해서 타이머가 끝나면 해제로직을 실행시켜야 되는걸까요??혹은, @Transactional 의 timeout 설정 값을 통해 선점 시간을 설정하는 방법도 가능할 것 같습니다.

안녕하세요. 분산락을 언제 쓰는게 좋을지 고민하다가 몇 가지 궁금증이 생겨 질문드립니다.분산 DB 환경이 무엇을 의미하는지?흔히 분산 DB 환경에서 낙관적, 비관적 락으로 동시성 문제를 해결하기 힘들다고 얘기하더라고요. 여기서 말하는 분산 DB 라는 것이 샤딩에 의해 여러 DB 서버가 있는 것인지, 동일한 데이터를 저장하는 DB 서버가 여러 대 있는 환경을 의미하는 것인지 모르겠습니다.예를 들어, Ticket 이란 데이터를 저장하는데 동일한 ticket 데이터가 DB server 1, DB server 2 에 저장되어 있는 환경일까요??만약 분산 DB 가 샤딩인 경우 비관적 락으로도 동시성 이슈를 해결할 수 있을 것 같은데 맞을까요?아래 그림처럼 ticketId = 1 인 티켓을 예매하기 위한 요청이 동시에 올 경우 입니다. 처음 x-lock 을 잡은 요청이 끝나야 뒤늦게 온 요청이 해당 티켓의 잔여 수량을 확인하고 예매 하기 때문에 샤딩으로 인한 분산 DB 에서는 비관적 락으로 동시성 이슈를 해결할 수 있을 것 같습니다.동일한 Ticket 데이터가 여러 DB 서버에 중복되어 저장된 분산 DB 환경에서는 분산락을 사용해야 될 것 같습니다.그러나, 샤딩은 동일한 Ticket 데이터에 접근하기 위해서는 동일한 서버로 접근하기 때문에 비관적 락으로도 충분히 해결 가능할 것 같아서 질문 드립니다!

github repository url: https://github.com/developer-yoni/ecommerce/tree/study/concurrency/redis여기서 study/concurrency/redis 브랜치를 확인해주시면 됩니다.StockServiceTest의 400번째 라인부터 503번째 라인까지테스트 코드가 작성되어 있습니다.큰 흐름은 동시성 이슈가 발생가능한 Stock에는 Lock을 걸지 않고,다른 Entity인 Market Entity에 PessimisticLock을 걸어,PessimisticLock을 분산락으로 활용하려는 시도 입니다.여기서 4_1 테스트는 Market에 PessimisticLock을 거는 트랜잭션과 Stock의 재고를 감소시키는 트랜잭션을 하나의 트랜잭션으로 묶었고,4_2 테스트는 별개의 트랜잭션으로 분리했습니다.이때 질문은 다음과 같습니다Q1. 동시성 이슈가 일어나지 않는 다른 Entity에 PessimisticLock을걸어 분산락처럼 활용하는게 문제가 되지 않을지 궁금합니다.혹시 문제가 된다면 , 어떤 측면에서 문제가 될지 궁금합니다.왜냐하면 어차피 동시성 이슈가 일어날 수 있는 측면의 값을 커밋하여 update함과 동시에PessmisticLock을 반환하는 것이니 문제가 되지 않을것이라고 생각했기 때문입니다.Q2. PessimisticLock을 건 트랜잭션이 커밋되거나 롤백될 때 비로소 PessmisticLock이 반환된다는 점을 근거로,4_2 테스트에서는 일부로 재고감소를 먼저 커밋한 후,Market의 PessimisticLock을 커밋하여,반드시 업데이트가 이뤄난 후 락을 반환하는것을 의도하였습니다.그러나 제 의도와 다르게 4_2 테스트는 계속 lock이 걸려있는?흐름을 보이면서 테스트에 실패합니다.그원인을 잘 모르겠습니다.바쁘신 와중에 답변 달아주셔서 감사합니다 강사님. 

질문의 의도처럼 변경하고자 하는 Entity는 A인데,사실 Entity B에 PessimisticLock을 획득하고, 획득한 쓰레드들에 한해서만 A를 변경하게 하면 PessimisticLock을 분산락으로 활용할 수 있을것 같았습니다.그러나 사실, 제가 테스트해본 결과 동시성 이슈가 발생해서, 그 원인을 모르겠습니다.제 생각은 PessimisticLock을 얻지 못한 쓰레드는 계속 대기하면서 변경하고자 하는 Entity B를 변경할 수 없을것이라고 생각했습니다.@Transactionalpublic void decrease2(Long id, Long quantity) {//0. 여기서 동일한 UserEntity에 대해 PesimisticLock을 건다 userRepository.findByIdWithPessimisticLock(userId); //1. stock 조회 Stock stock = stockRepository.findByIdAndEntityStatus(id, EntityStatus.ACTIVE).orElseThrow(() -> new ApiException(ApiCode.CODE_000_0011, "재고 감소시, 요청값으로 들어온 stockId로 Stock 조회 실패")); //2. 재고 감소 // 여기서 stock.decreaseInventoryQuantity(quantity); //3. 갱신된 값을 저장 stockRepository.saveAndFlush(stock); // 마지막에 트랜잭션 커밋 되야 -> Pessimistic Lock이 반환된다}

안녕하세요 강사님.제가 gpt를 통해 확인한 결과는, MySQL의 getLock(), releaseLock()은 트랜잭션 상태와는 무관하게 동작할 수 있다는 것이었습니다. 또한 NamedLockStockFacade에서 호출하는 StockService.decrease()는 REQUIRES_NEW에 의해 별도의 트랜잭션으로 관리되고 커밋 됩니다.따라서 StockService.decrease()에 의해 재고가 감소한 후,NamedLockStockService에서 releaseLock()으로 락을 반환할 때 예외가 터져도, 이미 커밋된 재고감소는 롤백되지 않을 것 같습니다.그럼에도 NamedLockStockFacade에서 @Transactional을 붙이신 별도의 의도가 있는지 궁금합니다.

안녕하세요 강사님. 강사님 강의를 예전에 들었는데 , 현업에서 실제 동시성 처리를 하려고 다시 보니 예전에 안보이던게 보이는 것 같습니다. 감사합니다.제가 질문하고 싶은 부분은 강의를 들으면서 습관적으로 OptimisticLockStockService에서 @Transactional을 붙였는데 무한루프에 빠졌습니다. 앞의 질문에 대한 답변으로 강사님이 보내주신 답변을 힌트로 그 원인을 생각했는데 , 이부분에 대해 피드백을 주시면 감사하겠습니다.제가 이해한 바로는 OptimisticLockStockFacade에 @Transactional을 붙이게 되면,트랜잭션이 재시도 로직을 포함해서 묶이면서, version 차이로 재시도를 할 때 새로운 버전으로 Stock을조회해와야 하는데, 아직 Transactional이 유지되고 있으니깐, Entity Manager에 있는 이전에 실패한 version의 Stock을 가지고 다시 update를 실패해서 무한루프에 빠진다고 생각했습니다.

강의 초반부 스레드는 start해서 작업이 끝나면 재사용할 수 없다고 하셨고 자바독에서도 아래와 같이 start()가 재사용되는 것은 legal하지 않다고 표현하고 있습니다It is never legal to start a thread more than once. In particular, a thread may not be restarted once it has completed execution.그런데 스레드풀 재사용 시에는 뭔가 다른 작업이 있을까 해서 강의와 함깨 디버깅해보니 addWorker()에서도 Worker에 할당된 스레드의 start()메소드로 호출하고 있었습니다. 스레드 풀의 경우 start()호출 후 메소드가 종료되었음에도 스레드를 재사용할 수 있는 이유는 무엇인가요? 질문을 작성하고 나서 조금 더 고민해보니 아래와 같은 결론에 도달했습니다.(혹시 틀린 내용이 있다면 수정 의견 부탁드립니다) 비슷한 고민을 하신 분이 있을 것 같아 글을 남겨둡니다.생성된 스레드의 start() 실행 -> Worker의 run()실행 -> Worker의 runWorker()실행 -> while()조건에 의해 무한 루프무한루프가 되는 이유 : getTask()를 통해 큐에서 작업을 꺼내와 실행하고 큐에 작업이 없을 경우 블록킹되므로 블로킹이 해제된 시점에서는 task변수에 작업이 할당되어 while조건문이 true가 됨

안녕하세요 강사님 좋은 강의 만들어 주셔서 감사합니다. 저는 무엇인가를 만들어보며 학습하는것을 선호 하는데요. 그래서 혹시 이 강의를 통해 얻게된 지식과 관련된 사이드 프로젝트 주제가 있다면 여쭤보고 싶습니다. 감사합니다.

https://www.inflearn.com/questions/655574위에 질문에서 saveAndFlush를 사용한 이유에 "save 메소드를 사용하게 된다면 데이터베이스에 바로 flush 가 되는것이 아니기때문에 synchronized 를 이용한 방법을 테스트할 때 오류가 날것입니다." 라고 답변해주셨는데 save를 사용하든 saveAndFlush를 사용하든 문제가 발생하지 않나요?flush를 바로 해준다고 데이터베이스에 커밋이 되는게 아니기때문에 충분히 동시성 문제가 생길 수 있다고 생각됩니다. 결국 아래 코드에서 saveAndFlush를 사용하든 save를 사용하든 실패하는것인데 왜 saveAndFlush를 사용하면 오류가 안난다고 하신건지 궁금합니다.@Transactional public synchronized void decrease(Long id, Long quantity) { Stock stock = stockRepository.findById(id).orElseThrow(); stock.decrease(quantity); stockRepository.saveAndFlush(stock); }

안녕하세요 강사님강의를 듣다가 이상한 것을 발견하여 문의 드립니다. Java Thread Fundamentals - 스레드 기본 API > interrupt() 강의중 InterruptExample 부분의 샘플 코드를 작성하고 테스트 및 정리를 하고 있습니다.  제가 현업에서 사용하는 JDK 11 을 사용해서 연습중에 이상한 현상을 발견하였습니다.JDK 17에서는 문제 없음을 확인하였습니다.  먼저 코드 구현체 부분입니다.public class TreadInterrupt { public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { System.out.println("thread 1 start"); System.out.println("thread 1 isInterrupted() = " + Thread.currentThread().isInterrupted()); }); Thread t2 = new Thread(() -> { System.out.println("thread 2 start"); t1.interrupt(); System.out.println("thread 1 isInterrupted() = " + t1.isInterrupted()); System.out.println("thread 2 isInterrupted() = " + Thread.currentThread().isInterrupted()); }); t2.start(); Thread.sleep(1000); t1.start(); t1.join(); t2.join(); System.out.println("작업 완려"); } } Thread#interrupt(), Thread#isInterrupted() 의 jdk 11과 17 버전입니다. // jdk 11 public class Thread { public boolean isInterrupted() { return isInterrupted(false); } @HotSpotIntrinsicCandidate private native boolean isInterrupted(boolean ClearInterrupted); public void interrupt() { if (this != currentThread()) { this.checkAccess(); synchronized(this.blockerLock) { Interruptible b = this.blocker; if (b != null) { this.interrupt0(); b.interrupt(this); return; } } } this.interrupt0(); } private native void interrupt0(); } // jdk 17 public class Thread { private volatile boolean interrupted; public boolean isInterrupted() { return interrupted; } public void interrupt() { if (this != Thread.currentThread()) { checkAccess(); // thread may be blocked in an I/O operation synchronized (blockerLock) { Interruptible b = blocker; if (b != null) { interrupted = true; interrupt0(); // inform VM of interrupt b.interrupt(this); return; } } } interrupted = true; // inform VM of interrupt interrupt0(); } }위 코드와 같이 jdk 17 은 Thread 객체 내 interrupted 필드를 둠으로써 인터럽트의 상태를 관리하지만 jdk 11 같은 경우에는 native 메서드를 이용해서 인터럽트의 상태를 관리하는 것을 확인할 수 있었습니다.  이 때 jdk 11에서 위 코드를 실행시키면 결과가 아래 와 같이 출력되는것을 확인하였습니다. thread 2 start thread 1 isInterrupted() = false thread 2 isInterrupted() = false thread 1 start thread 1 isInterrupted() = false 작업 완려프로세스 실행을 반복하거나 sleep 의 시간을 늘려보아도 항상 아래와 같은 동일한 결과가 나왔습니다. 하지만 이 코드를 디버그 모드를 이용해서 동작시킨 경우 완전히 다른 결과가 나왔습니다.break point 는 t1.interrupt() 부분에 걸었으며 실제 인터럽트 내부 코드 동작 부분은 확인하지 않고 F8 을 이용해서 코드라인을 프로세스가 종료할 때 까지 넘김thread 2 start thread 1 start thread 1 isInterrupted() = true thread 1 isInterrupted() = true thread 2 isInterrupted() = false위는 실제로 디버그 모드로 동작 시켰을때 처리 결과입니다. 아무리 생각해도 동일한 코드, 동일한 로직인데 디버그 모드일때 정상적으로 출력되고 일반적으로 실행하였을때 인터럽트의 상태가 모두 false 가 나온다는 것이 이해되지 않아 문의 남겨봅니다.  

네임드락에서 Propagation.REQUIRES_NEW을 설정하는 이유로 부모 트랜잭션과 별도로 실행되어야 한다고 하셨는데, 왜 별도로 실행해야하는지 궁금합니다.다른분들 질문에서 아래처럼 답변해주셨는데 제가 이해한바가 맞을까요?부모의 트랜잭션과 동일한 범위로 묶인다면 Synchronized 와 같은 문제가 발생합니다. Database 에 commit 되기전에 락이 풀리는 현상이 발생합니다. 그렇기때문에 별도의 트랜잭션으로 분리를 해주어 Database 에 정상적으로 commit 이 된 이후에 락을 해제하는것을 의도하였습니다. 핵심은 lock 을 해제하기전에 Database 에 commit 이 되도록 하는것입니다. Synchronized와 같은 문제 : 트랜잭션이 시작 -> 락 획득 -> 로직 수행 -> 락 반납 -> 트랜잭션 커밋과 같이 커밋되기 전에 락 반납한 상황에서 다른 요청이 들어올 수 있기 때문에 동시성 이슈는 여전히 발생위의 내용대로라면 부모 트랜잭션의 로직은 보류해두고, 동시성이 발생하는 로직만 따로 분리해서 새로운 트랜잭션으로 로직 실행후 commit하고, 부모 트랜잭션의 나머지 로직 수행으로 이해했는데, 제가 응용한 프로젝트는 왜 네임드락의 정합성이 안맞는지 궁금합니다..동시성 테스트할때 시간도 엄청 오래걸립니다.2번 질문에 이어서 제가 위에서 이해한대로 트랜잭션 로그도 확인해봤는데, 부모 트랜잭션 이후로 새로운 트랜잭션 완료한 뒤 기존 트랜잭션을 처리하는걸로 로직은 잘 동작하는데 부정합이 이유가 무엇일까요..?20240302 22:10:41.691 [http-nio-8080-exec-1] INFO o.a.c.c.C.[.[.[/] - Initializing Spring DispatcherServlet 'dispatcherServlet' 20240302 22:10:41.691 [http-nio-8080-exec-1] INFO o.s.w.s.DispatcherServlet - Initializing Servlet 'dispatcherServlet' 20240302 22:10:41.695 [http-nio-8080-exec-1] INFO o.s.w.s.DispatcherServlet - Completed initialization in 4 ms 20240302 22:10:41.957 [http-nio-8080-exec-1] TRACE o.s.t.i.TransactionInterceptor - Getting transaction for [com.flab.offcoupon.service.CouponIssueService.issueCoupon] 20240302 22:10:41.957 [http-nio-8080-exec-1] INFO c.f.o.s.CouponIssueService - 트랜잭션 1 : 쿠폰 발급 요청. eventId : 1, couponId : 1, memberId : 1 20240302 22:10:41.988 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. SELECT id, category, description, start_date, end_date, daily_issue_start_time, daily_issue_end_time, created_at, updated_at FROM event WHERE id = 1; {executed in 14 msec} 20240302 22:10:41.998 [http-nio-8080-exec-1] INFO j.resultsettable - |---|---------|-------------|-----------|-----------|-----------------------|---------------------|--------------------|--------------------| |id |category |description |start_date |end_date |daily_issue_start_time |daily_issue_end_time |created_at |updated_at | |---|---------|-------------|-----------|-----------|-----------------------|---------------------|--------------------|--------------------| |1 |바디케어 |바디케어 전품목 할인 |2024-02-27 |2024-02-29 |13:00:00 |15:00:00 |2024-02-27T22:34:01 |2024-02-27T22:33:57 | |---|---------|-------------|-----------|-----------|-----------------------|---------------------|--------------------|--------------------| 20240302 22:10:42.012 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. SELECT GET_LOCK('namedLock', 3000); {executed in 9 msec} 20240302 22:10:42.013 [http-nio-8080-exec-1] INFO j.resultsettable - |----------------------------| |get_lock('namedlock', 3000) | |----------------------------| |1 | |----------------------------| 20240302 22:10:42.014 [http-nio-8080-exec-1] INFO c.f.o.s.CouponIssueService - getLock = 1 20240302 22:10:42.014 [http-nio-8080-exec-1] TRACE o.s.t.i.TransactionInterceptor - Getting transaction for [com.flab.offcoupon.repository.IncreaseIssuedCoupon.increaseIssuedCouponQuantity] 20240302 22:10:42.014 [http-nio-8080-exec-1] INFO c.f.o.r.IncreaseIssuedCoupon - 트랜잭션 2 쿠폰 발급 수 증가. couponId : 1 20240302 22:10:42.015 [http-nio-8080-exec-1] INFO c.f.o.r.IncreaseIssuedCoupon - 트랜잭션 2 쿠폰 조회. couponId : 1 20240302 22:10:42.029 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. SELECT id, event_id, discount_type, discount_rate, discount_price, coupon_type, max_quantity, issued_quantity, validate_start_date, validate_end_date, created_at, updated_at, version FROM coupon WHERE id = 1; {executed in 13 msec} 20240302 22:10:42.041 [http-nio-8080-exec-1] INFO j.resultsettable - |---|---------|--------------|--------------|---------------|------------------------|-------------|----------------|--------------------|------------------|-----------------|-----------------|--------| |id |event_id |discount_type |discount_rate |discount_price |coupon_type |max_quantity |issued_quantity |validate_start_date |validate_end_date |created_at |updated_at |version | |---|---------|--------------|--------------|---------------|------------------------|-------------|----------------|--------------------|------------------|-----------------|-----------------|--------| |1 |1 |PERCENT |50 |[null] |FIRST_COME_FIRST_SERVED |500 |10 |2024-02-01T00:00 |2024-02-05T00:00 |2024-02-01T00:00 |2024-02-01T00:00 |0 | |---|---------|--------------|--------------|---------------|------------------------|-------------|----------------|--------------------|------------------|-----------------|-----------------|--------| 20240302 22:10:42.058 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. UPDATE coupon SET issued_quantity = 11 WHERE id = 1 {executed in 15 msec} 20240302 22:10:42.059 [http-nio-8080-exec-1] TRACE o.s.t.i.TransactionInterceptor - Completing transaction for [com.flab.offcoupon.repository.IncreaseIssuedCoupon.increaseIssuedCouponQuantity] 20240302 22:10:42.090 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. SELECT RELEASE_LOCK('namedLock'); {executed in 29 msec} 20240302 22:10:42.092 [http-nio-8080-exec-1] INFO j.resultsettable - |--------------------------| |release_lock('namedlock') | |--------------------------| |1 | |--------------------------| 20240302 22:10:42.093 [http-nio-8080-exec-1] INFO c.f.o.s.CouponIssueService - releaseLock = 1 20240302 22:10:42.138 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. SELECT EXISTS (SELECT 1 FROM coupon_issue WHERE member_id = 1 AND coupon_id = 1 AND DATE (created_at) = 2024-02-29 LIMIT 1); {executed in 25 msec} 20240302 22:10:42.139 [http-nio-8080-exec-1] INFO j.resultsettable - |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |exists (select 1 from coupon_issue where member_id = 1 and coupon_id = 1 and date (created_at) = '2024-02-29' limit 1) | |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |false | |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 20240302 22:10:42.176 [http-nio-8080-exec-1] DEBUG j.sqltiming - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44) 1. INSERT INTO coupon_issue (member_id, coupon_id, coupon_status, created_at, updated_at) VALUES (1, 1, 'NOT_ACTIVE', 2024-03-02T22:10:42.141176, 2024-03-02T22:10:42.141176) {executed in 32 msec} 20240302 22:10:42.178 [http-nio-8080-exec-1] TRACE o.s.t.i.TransactionInterceptor - Completing transaction for [com.flab.offcoupon.service.CouponIssueService.issueCoupon]  

NamedLock을 사용한 예제실습 중 질문입니다NamedLockStockFacade의 decrease 메소드에 @Transactional 을 걸고 StockService의  decrease 메소드에는 @Transactional 을 걸지 않아도 잘 작동해야하는거 같은데, 데드락에 걸리는거 같습니다. 그 이유가 궁금합니다제 생각에는 NamedLockStockFacade의decrease 메소드에 @Transactional 을 걸면,lockRepository.getLock(id.toString()), stockService.decrease(id, quantity), lockRepository.releaseLock(id.toString()) 이 3 메소드가 모두 한 트랜잭션 안에서 처리되므로 lock을 걸고 lock을 해제하는 그 사이에 재고를 감소하므로 아무 문제가 없어보여서 질문드립니다.

 Optimistic Lock은 충돌이 빈번할 경우 적절하지 않다고 하는데, 충돌이 기준이 어떤건지 궁금합니다. 별도로 프로젝트에서 Mybatis랑 같이 쿠폰발급 프로젝트에서 응용중입니다.전 쿠폰 500개를 기준으로 발급된 수량을 합산하는 로직입니다.스레드 100개기준으로 동시성테스트를 진행했을때 69개만 적용되더라구요. 재시도 로직에서 Thread.sleep(1000)으로 하면 98개까지 적용됩니다. 그런데 스레드 10개를 기준으로 동시성 테스트를 진행했을때는 정합성이 맞고, 스레드1000개를 돌려버리면 500개가 전부다 발급됩니다. 1000개 중에 몇개는 실패하고, 몇개는 성공하고 그래서 500개 전부 다 발급된 상황이라고 예상됩니다.Q1. 충돌이 많은 상황이라는게 동시에 여러 스레드가 접근하는 걸 의미하는게 맞나요? 충돌의 기준은 무엇인지, 어플리케이션 내부 로직마다 다른걸까요?Q2. 충돌이 빈번하지 않을때 낙관적락을 사용하는 경우가 어떤 경우인지 궁금합니다.. 정합성이 많이 떨어진다고 생각하는데 실제로 현업에서 많이 사용하나요?Q3. 데이터베이스에 락을 걸지 않아서 성능상 이점이 있다고 하셨는데, 제가 테스트해봤을때는 pessimisticLock보다 Mysql에 더 부하가 많이가더라구요. 재시도로직으로 I/O작업이 더 많이 일어나서 그런것 같은데, 말씀하시는 '성능상 이점'이라는건 어떤건지 궁금합니다.

현재 강의에서는 정상적인 코드면 무한루프가 종료되는걸로 생각하고 있습니다.하지만1. 재고가 감소시켜야 하는 수량 보다 적을 경우는 무한루프를 도는것을 확인했습니다.어떻게 예외처리를 해야할 지 잘 모르겠어서 질문드립니다 ㅠ public class Stock { // ... public void decrease(Long quantity) { if (this.quantity - quantity < 0) { throw new RuntimeException("재고 수량이 부족합니다."); } this.quantity -= quantity; } }public class OptimisticLockService { private final StockRepository stockRepository; @Transactional public void decrease(Long id,Long quantity){ Stock stock = stockRepository.findByIdWithOptimisticLock(id); if (stock.getQuantity() < quantity) { throw new RuntimeException("재고 수량이 부족합니다."); } stock.decrease(quantity); } }stock 클래스에서 예외처리를 하는것이 좋을지 서비스 클래스에서 예외처리를 좋을지?!예외를 주고 OptimisticLockStockFacade에 대한 무한루프를 어떻게 처리할지..강의 잘 들었습니다 답변 부탁드려용 .. @Component @RequiredArgsConstructor public class OptimisticLockStockFacade { private final OptimisticLockService optimisticLockService; public void decrease(Long id, Long quantity) throws InterruptedException { while (true) { try { optimisticLockService.decrease(id, quantity); break; }catch(Exception e) { Thread.sleep(50); } } } } 현재 아래코드를 실행하면 무한루프가 나갑니다.! @Test @DisplayName("재고가 없을시 재고감소 로직 요청시 예외가 일어난다.") void decreaseStockZero() { //given //when //then assertThatThrownBy(() -> optimisticLockStockFacade.decrease(1L, 101L)) .isInstanceOf(RuntimeException.class) .hasMessage("이미 품절된 상품입니다."); }

다대일에서 한 스레드가 I/O 발생 시 프로세스 자체를 블록하기 때문에 모든 스레드들이 Block이 발생하는데다대다에서는 한 스레드가 I/O 발생 시 커널이 다른 스레드의 수행을 스케줄할 수 있는 이유가 궁금합니다.다대일도 다대다처럼 커널이 다른 스레드의 수행을 스케줄하면 안되나요?왜 다대일만 프로세스 블록시키고 다대다는 프로세스를 블록시키지 않고 모든 스레드들이 Block이 발생하지 않나요?

안녕하세요 강사님! 시큐리티부터 열심히 수강중입니다! 혹시 강의내용을 정리해서 블로그에 포스팅 해도 괜찮을까요? 항상 좋은 강의 올려주셔서 감사합니다!

위의 질문과 똑같은 질문입니다!@SpringBootTestclass stockServiceTest {@Autowired private StockService stockService; @Autowired private StockRepository stockRepository; @BeforeEach public void setUp(){stockRepository.saveAndFlush(new Stock(1L,100L)); }@AfterEach public void after(){stockRepository.deleteAll(); }@Test @DisplayName("동시에 100개 요청")void 동시에_100개의_요청() throws InterruptedException {//given int threadCount = 100; // ExecutorService는 비동기로 실행하는 작업을 단순화하여 사용할 수 있게하는 자바 api ExecutorService executorService = Executors.newFixedThreadPool(32); // CountDownLatch는 다른 쓰레드에서 수행중인 작업이 완료될때까지 대기할 수 있도록 도와주는 클래스 CountDownLatch latch = new CountDownLatch(threadCount); for (int i = 0; i < threadCount; i++) {executorService.submit(()->{try {stockService.decrease(1L,1L); }finally {latch.countDown(); }}); }latch.await(); //when //then Stock stock = stockRepository.findById(1L).orElseThrow(); assertThat(stock.getQuantity()).isEqualTo(0); }@Test @DisplayName("재고감소")void decreaseStock(){//given //when stockService.decrease(1L,1L); Stock stock = stockRepository.findById(1L).orElseThrow(); //then assertThat(stock.getQuantity()).isEqualTo(99); }}1번테스트와 2번테스트를 각각 테스트를 실행할 경우 테스트가 성공하지만 전체 테스트를 실행하게 하여 1번테스트와 2번테스트를 돌리면 No value presentjava.util.NoSuchElementException: No value present라는 예외가 뜹니다.@BeforeEach와 @AfterEach가 있어서 문제가 없을거라 생각하는데 왜 전체 테스트중 동시에_100개의_요청이라는 테스트가 실패하는건가요?

@Transactional(isolation = Isolation.SERIALIZABLE) 이렇게 해도 동시성 제어 테스트에 실패해서 검색해보니까 SERIALIZABLE 격리 단계는 락이 걸려 있는 동안 update를 못하는거지 select는 가능하다 라는 식의 글을 봤습니다. 그러면 각 스레드들이 접근해서 select만 한 상태에서 대기하고 있다가 락이 풀리면 update를 시도하는 건가요? 그래서 테스트에 실패하는 건가요?

안녕하세요 강사님 강의(싱글스레드 & 멀티스레드)를 듣다가 궁금한 점이 생겼습니다.예제 코드에서 1 ~ 1000을 더하는 for문의 실행시간은 약 2초 정도가 나오고 이를 2개의 스레드로 처리하면 약 1초 정도가 나왔는데요.synchronized키워드를 이용해서 lock을 걸 경우 해당 자원에는 하나의 스레드만 접근하게 되므로 예제의 경우 사실상 병렬처리가 불가능함에도 처리속도가 더 빠른 이유는 무엇인가요?사양은 다음과 같습니다 : 인텔® 코어™ i5-7500 프로세서 ; 스레드 수. 4 ;GPT 도움을 받아 아래와 같이 추측해 봤는데 맞을까요?싱글스레드 프로그램 : sleep(1)초에 의해 for루프 안에서 sleep 상태 발생멀티스레드 프로그램 : thread1의 sleep동안 thread2가 연산 수행 -> 싱글스레드와 다르게 sleep 상태에 의해 지연되는 시간이 없음