-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@Async 메서드 사용 예시 작성 #25
Conversation
✅ Test : 테스트 코드 추가 1. 비동기 서비스 클래스 생성 2. 생성한 메서드에 대한 기본 테스트 작성 1. 여러 입출력 상황에 맞게 비동기 메서드 호출과 비동기 객체 병합 방법 강구
1. 메서드가 비동기 메서드인지 확인하는 테스트 작성 2. @async를 붙인 메서드가 비동기로 동자가하지 않고 하나의 쓰레드에서 동작한다.
✅ Test : 테스트 코드 추가 1. 다중 스레드 설정을 위해 taskExecutor 메서드 빈으로 저장 2. 비동기 메서드 다중 호출 시 병렬적으로 동작하는지 testGetMultiString에서 검증 3. 비동기 메서드의 지연시간이 길어질 경우 타임아웃 발생하도록 하는 부분 검증
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #25 +/- ##
==============================================
+ Coverage 62.50% 89.23% +26.73%
- Complexity 4 23 +19
==============================================
Files 2 9 +7
Lines 8 65 +57
Branches 0 1 +1
==============================================
+ Hits 5 58 +53
- Misses 3 7 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
직접 실행해보고 마저 리뷰할게요! |
✅ Test : 테스트 코드 추가 1. 비동기 호출을 10회 하는 비동기 메서드를 10회 호출하는 calculateRunTime 작성 2. 비동기 호출이 100회 일 때 50개는 쓰레드가 실행하고 나머지 50개는 블록킹 큐에서 대기한다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
다음 이슈에 대한 요구사항과 부합하지 않습니다.
-
위 요구사항을 기반으로 생각했을 때,
@Async
어노테이션과CompletableFuture
, 둘 중 하나만 사용하는 것이 적절하다고 생각합니다. -
Spring 프레임워크의
@Async
만을 활용하여 비동기를 구현해보는 것이 어떨까 제안해봅니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
불필요한 .gitignore
변경
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
댓글 남겼습니다!
하지만 말 그대로 @Async
어노테이션의 사용 예시니까 특별히 수정할 필요성은 없을 것 같아요.
다만, 이 코드를 병합하더라도 결국 큰 수정이 이뤄질 것 같다는 생각이 듭니다.
지금 보면 오히려 요구사항이 불명확하다는 느낌을 받았는데,
이 부분을 확실하게 잡고 넘어가면 혼선을 줄일 수 있을 것 같네요
✅ Test : 테스트 코드 추가 1. BasicCounter 구현. 멀티 쓰레드로 카운터 동시 업데이트 불가 테스트 2. SynchronizedCounter 구현. 멀티 쓰레드로 카운터 동시 업데이트 가능 테스트. Synchronized만 사용했을 때는 0.5s 소요 3. Completable 사용하면 실행시간이 대폭 감소
1. SynchronizedCounter 테스트의 실질적 실행시간을 로깅하도록 리팩토링
✅ Test : 테스트 코드 추가 1. CompletableFuture를 이용한 카운터 작성 2. 카운터에 int가 아닌 CompletableFuture<Integer>를 저장 3. 작업의 완성본을 저장하지 않고 작업 진행 중인 Future 객체를 저장하는 점에서 추후 캐싱 시나리오에 도움될 것으로 보임
# Conflicts: # src/main/java/com/thread/concurrency/counter/BasicCounter.java # src/main/java/com/thread/concurrency/counter/Counter.java
1. 컨슈머는 브로커에게서 이벤트를 가져와 처리한다. 2. 프로듀서는 브로커에게 이벤트를 저장한다. 3. 브로커는 큐를 관리하고 큐에 이벤트 삽입과 제거를 담당한다.
1. 프로듀서-컨슈머 패턴을 이용한 카운터 구현을 위해 테스트를 작성 2. 시간 측정 결과 기존 CompletableFutureCounter에 2배 시간이 걸리는 걸로 나왔다. To Do CompletableFutureCounterTest와 QueueCounterTest에 쓰이는 쓰레드 수를 같게해서 다시 시간을 측정해보기
1. 브로커를 테스트에서 제거 2. 단일한 큐를 컨슈머와 프로듀서가 공유 3. 컨슈머가 카운터를 업데이트하는 역할을 가짐 To Do 컨슈머의 consumEvent를 실행하는 스레드와 show를 호출하는 메인 스레드 간 싱크가 맞지 않는다. 모든 consumEvent가 끝나고 show를 호출할 수 있는 방법이 필요하다.
1. 아직 프로듀서-컨슈머 문제해결 못함 2. consumer가 아직 이벤트를 처리 중임을 다른 스레드가 알 수 있거나 이벤트를 전부 끝냈다는 정보를 다른 스레드가 알 수 있게할 필요가 있다.
개요
taskExecutor
빈 등록변경 사항
추가 정보
관련 이슈