[section7-1강] 출금 예제

안녕하세요. so1245p님이번 강의 마지막에 설명드린 것 처럼 balance 값은 메모리 가시성 문제가 발생할 수 있습니다!다만 발생 가능성이 매우 낮기 때문에 눈으로 확인하는 것은 쉽지 않습니다.추가로 log(), sleep()과 같은 코드가 실행될 때, 컨텍스트 스위칭이 발생하면서 메모리 가시성 문제가 해결되는 것 처럼 보일 수는 있습니다.감사합니다.

오타 제보합니다.

정도현님 감사합니다 🙂다음 패치에 반영할게요.

저는 왜 EOFException이 아니라 SocketException이 발생할까요 ?

안녕하세요. ppj2130님OS와 자바 버전에 따라서 다른 결과가 나올 수는 있습니다 🙂 만약 더 자세한 내용이 궁금하시다면, 현재 사용중인 OS와 자바 버전을 알려주세요.추가로 코드에 다른 부분이 있을 수도 있으니 실제 동작하는 전체 프로젝트를 ZIP파일로 압축해서 구글 드라이브로 공유해서 링크를 남겨주세요.구글 드라이브 업로드 방법은 다음을 참고해주세요.https://bit.ly/3fX6ygx 주의: 업로드시 링크에 있는 권한 문제 꼭 확인해주세요 추가로 다음 내용도 코멘트 부탁드립니다.1. 문제 영역을 실행할 수 있는 방법2. 문제가 어떻게 나타나는지에 대한 상세한 설명 (오류 화면, 오류 로그 포함)링크: 공식 서포터즈링크: 자주하는 질문감사합니다.

querydsl 처음 설정 후 테스트코드 돌려보는데 오류 원인을 모르겠어요

안녕하세요. 테렌테렌님도움을 드리고 싶지만 질문 내용만으로는 답변을 드리기 어렵습니다.실제 동작하는 전체 프로젝트를 ZIP파일로 압축해서 구글 드라이브로 공유해서 링크를 남겨주세요.구글 드라이브 업로드 방법은 다음을 참고해주세요.https://bit.ly/3fX6ygx주의: 업로드시 링크에 있는 권한 문제 꼭 확인해주세요추가로 다음 내용도 코멘트 부탁드립니다.1. 문제 영역을 실행할 수 있는 방법2. 문제가 어떻게 나타나는지에 대한 상세한 설명 (오류 화면, 오류 로그 포함)링크: 공식 서포터즈링크: 자주하는 질문감사합니다.

이런 상황에선 어떻게 구현 하시는 지 궁금합니다.

안녕하세요. 토니님개발은 유지보수하기 쉬운 단순한 방법과 복잡한 성능 최적화 사이에서 적절한 고민이 필요합니다. 항상 그런 것은 아니지만 보통 성능을 최적화 할 수 록 더 복잡한 선택들이 필요합니다.반대로 말하면 너무 많은 성능 최적화를 하면 유지보수가 매우 어려워질 수 있습니다.개발은 어떤 정답이 있는 것 처럼 보이지만, 사실은 수 많은 선택지 중에 현재 프로젝트의 상황에 맞는 적절한 방법을 선택하는 것이 필요합니다. 저는 그래서 개발이 참 즐겁더라구요 :)이 경우 예를 들면 단계별로 고민해야 하는 점은 다음과 같습니다.1. 트래픽이 매우 적고, 동시 호출에 대한 이슈가 없다: 현재 방식은 가장 유지보수하기 편하고 재사용 가능한 방식입니다. 코드도 자바와 객체를 통해서 쉽게 바로 이해할 수 있습니다.2. 트래픽이 조금 있고, 동시 호출에 대한 이슈가 있다: 이 경우 데이터베이스가 제공하는 update 쿼리를 직접 사용하는 것이 좋습니다. update set viewCount = viewCount + 1을 사용하는 것이지요. 이 경우 데이터베이스가 제공하는 기능에 종속적이기 때문에 유지보수 관점에서는 1번의 경우보다 좋지 않지만, 동시성 문제도 데이터베이스를 통해 원자적으로 해결되고, 조회 쿼리도 하나 줄일 수 있기 때문에 성능 관점에서 더 나은 선택입니다. 보통 실무에서 간편하게 많이 선택하는 방법 중 하나입니다. 참고로 JPA의 경우에도 JPQL을 통해 update 쿼리를 직접 사용할 수 있습니다.3. 트래픽이 매우 많아진다: 이 경우 다양한 고민이 필요해집니다.viewCount용 테이블을 별도로 분리한다. viewCount용 테이블viewCount를 캐시를 사용해서 처리한다.(메모리 캐시, redis 등등, viewCount가 정밀하지 않아도 됨)viewCount를 메모리나 로그에 같은 곳에 모은 다음에 주기적으로 배치를 통해 서비스 캐시나 DB에 저장한다. (viewCount가 정밀하지 않아도 됨)참고로 락의 경우는 서비스에서 가급적 최소화 해야 합니다.그리고 여기서 매우 중요한 부분이 있는데요. 조회수를 은행 예금처럼 정밀하게 100% 맞추어서 제공해야 하는가? 입니다. 만약 그렇게 해야 한다면 쉽게 성능을 최적화 하기가 매우 어려워집니다.그런데 대부분의 사용자는 뷰 카운터를 은행 예금 처럼 중요하게 생각하지는 않을거에요. 이런 부분을 기획자와 잘 이야기해서 현실적인 범위안에서 서비스 정책을 정하게 되면 장비 비용도 아끼면서 성능 최적화도 더 잘 할 수 있을거에요.도움이 되셨길 바래요 :)