결국엔 둘 다 다른 스레드가 접근하지 못 하게 락을 걸어놓는 건데 1,000개 스레드로 동시서 테스트 해보니까
synchronized는 쓰로우풋이 6.7/sec이고 배타락을 이용한게 25.4/sec로 성능 차이가 되게 많이 나는데
synchronized는 자바 객체 안에 내장된 락을 걸고 배타락은 데이터 베이스의 락을 이용한다는 차이만 아는데 이게 왜 이 정도의 성능 차이를 발생시키는지를 모르겠음 ㅠㅠ
결국엔 둘 다 다른 스레드가 접근하지 못 하게 락을 걸어놓는 건데 1,000개 스레드로 동시서 테스트 해보니까
synchronized는 쓰로우풋이 6.7/sec이고 배타락을 이용한게 25.4/sec로 성능 차이가 되게 많이 나는데
synchronized는 자바 객체 안에 내장된 락을 걸고 배타락은 데이터 베이스의 락을 이용한다는 차이만 아는데 이게 왜 이 정도의 성능 차이를 발생시키는지를 모르겠음 ㅠㅠ
배타락이 db 배타락 말하는거?
응응 Pessimistic.WRITE 말하는거였어
본문에 내용 조금 추가했는데 객체 내장 락 vs 데이터베이스 락 정도의 차이만 아는데 이게 왜 성능에 큰 영향을 주는지 모르겠음... 락을 걸면 다른 스레드가 멈추는 건 똑같은데
그건 당연히 synchronized가 더 빠르지 내부 동작 제껴놓고 생각해봐도 네트워크를 통해야하는 것과 아닌 것은 어마어마한 차이가 있어
엥 근데 왜 지금 진행한 테스트는 배타락이 더 성능이 좋지..?
다중 스레드가 늘어날수록 배타락이 더 효율이 좋아지는 경우가 있을까?
개인 pc에서 진행한 테스트면 신뢰도가 낮음
개인 PC라는게 어플리케이션은 로컬 환경으로 돌리고 DB는 RDS로 띄워놓은 환경을 말하는거지?
어플리케이션도 별도 테스트용 서버에 띄워둬야지
아 그걸 안 했네... 테스트 다시 해야겠다 ㅠㅠㅠㅠ 고마워 대기형!
그리고 실무에서는 synchronized로 동시성 제어 안 하지? 프로세스가 여러개면 동시성 제어가 안 되는 걸로 알고있어서!
synchronized로 동시성 제어해야할 때가 있고 분산락으로 동시성 제어해야할 때가 있지 니 말대로 멀티 프로세스에서 락을 걸려면 분산락을 걸어야할테고 단일 프로세스 내에서 락을 걸려면 synchronized면 충분하겠지
단일 프로세스, 단일 DB = synchronized로 충분 멀티 프로세스, 단일 DB = 배타락으로 제어 가능 멀티 프로세스, 다중 DB = 분산락 으로 해야하는게 맞을까..?
DB 배타락도 분산락이라니까 DB를 공유하기 싫으면 redis 같은거라도 공유해야 분산락이 가능하지
아 이제 이해해따!!! 고미워 대기형! 테스트 서버에 올려놓고 다시 테스트해볼게!
단일 프로세스에서 synchronized로 충분하다는건 DB를 다룰때 충분하단 이야기가 아니었어 DB 다루는데 동시성을 synchronized로 제어한다는 상상을 못하고 한 말임
반고닉아 synchronized가 걸린 메소드에 @Transactional을 붙이면 분실 문제가 생기는 이유가 모야...? 트랜잭션1,2가 있으면 1이 먼저 Read, Write를 실행하고 커밋까지 다 되고 2가 Read, Write를 실행해서 업데이트 하는데는 문제 없지 않아..?
니가 글쓴이의 의도를 제대로 파악한거고, 나는 제대로 파악 못한거였음;; 댓 지울 필요 없었는데
아 synchronized를 붙인다고 해서 트랜잭션까지 적용되는게 아니구나 aop 프록시도 찾아서 공부해볼게 고마워! 대기형이 말한 부분도 이해했음 둘 다 고마워!