묻고 답해요
161만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
해결됨앨런 Swift Concurrency for Swift 6 (Part-2)
Actor에서 Task vs Task.detached 사용 시 재진입 문제 질문
actor TaskImageDownloader { /// (다운로드) 상태를 저장하기 위한 열거형 정의 enum DownloadState { case completed(UIImage) case loading(Task<UIImage, Error>) case failed } private(set) var cache: [String: DownloadState] = [:] func image(from url: String) async throws -> UIImage { /// 기존에 저장된 상태가 있는 경우 (캐시 먼저 확인) if let cachedState = cache[url] { switch cachedState { case .completed(let image): /// 이미지 리턴 return image case .loading(let task): /// 작업(Task)을 기다렸다가 ===> 이미지 리턴 return try await task.value case .failed: throw "이미지 다운로드 실패" } } /// 작업(Task)을 생성 let task = Task.detached<UIImage, Error> { let image = try await downloadImage(from: url) return image } /// 일단 (완료되지 않은) 작업 상태를 보관 cache[url] = .loading(task) do { /// 작업의 완료를 기다렸다가 ===> 완료되면 ===> 완료상태(이미지)로 바꿔서 보관 let image = try await task.value cache[url] = .completed(image) return image } catch { cache[url] = .failed // 에러 발생의 경우 throw "이미지 다운로드 실패" } } } Actor에서 Task vs Task.detached 사용 시 재진입 문제 질문안녕하세요.위 코드에서 Task.detached 대신 일반 Task {}를 사용하면 재진입 문제가 발생할 수 있을 것 같아 질문드립니다.제가 이해한 바로는:Task {}를 사용하면 생성된 작업이 actor의 context를 상속받아 serial executor에서 실행됩니다다운로드 작업 중 await를 만나면 actor가 suspension되고, 이 시점에 다른 스레드에서 해당 actor에 재진입할 수 있습니다따라서 동일한 URL에 대해 중복으로 다운로드 작업이 생성될 가능성이 있습니다반면 Task.detached를 사용하면 actor context와 독립적으로 실행되어 이러한 재진입 문제를 방지할 수 있는 것으로 이해했습니다.제가 이해한 내용이 맞는지 확인 부탁드립니다. 감사합니다.
-
미해결재고시스템으로 알아보는 동시성이슈 해결방법
낙관적 락을 사용할 떄 차이점
@Version만 붙여도 자동으로 낙관적 락을 적용 시켜주는 걸로 알고 있습니다. 근데 강의에서는 @Lock(LockModeType.OPTIMISTIC) 을 이용해서 조회 시점부터 락을 거는 이유가 있을까요?@Lock(LockModeType.OPTIMISTIC) 를 제거하고 동시성 테스트 했을 떄도 정상적으로 돌아가긴 합니다. 어떤 차이가 있을까요
-
미해결재고시스템으로 알아보는 동시성이슈 해결방법
동시성 검증 코드에 관한 문의
안녕하세요. 동시성 검증 코드 관련하여 궁금한 점이 있어 문의드립니다.강의에서 ExecutorService를 사용하여 동시성 검증을 수행하신 것으로 보았는데, 이 방식만으로 실제 동시성 문제를 충분히 검증할 수 있을지 궁금합니다.컨텍스트 스위칭 타이밍에 따라 경합이 발생하지 않을 가능성도 있을 것 같습니다.예전에 면접에서 비슷한 질문을 받았는데, ExecutorService 기반 테스트만으로는 실제 운영 환경(수십만 건의 요청)에서 발생할 수 있는 동시성 이슈를 완전히 검증하기 어렵다는 지적을 받은 적이 있습니다.혹시 이러한 한계를 보완할 수 있는 다른 검증 방법이나 접근 방식이 있을까요?
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
오타 제보
4번 스레드 제어와 생명 주기2 PDF의 24페이지 "그리고 스캐줄링 큐 ..." -> "그리고 스케줄링 큐 ..." 7번 고급동기화 PDF의 1페이지 "LockSupport의 대표적인 기능은 가능과 같다" -> "LockSupport의 대표적인 기능은 다음과 같다"
-
미해결재고시스템으로 알아보는 동시성이슈 해결방법
단일연산
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. final Stock stock = stockRepository.getByProductId(productId); stock.decrease(quantity); stockRepository.save(stock) public void decrease(final Long quantity) { if (this.quantity - quantity < 0) { throw new RuntimeException("재고 부족"); } this.quantity -= quantity; } 락을 건 이유는 decrease 로직에서 quantity를 줄이고 다시 저장했기 때문이라 생각했습니다. stock 상태가 코드레벨에서 변하기 때문에 발생하기 때문입니다.다만 코드레벨에서 변경하지 않고 디비에서 직접 변경한다면(update stock quantity=quantity-1 과 같이) update 자체가 배타락이기 때문에 굳이 락을 걸지 않아도 된다고 판단하였습니다. 그래서 단일 연산으로 해결할 수 없는 상황은 quantity 필드 뿐만 아니라 다른 필드에도 영향이 미칠 때라 생각했습니다. stock 필드에 soft delete 필드 delYn을 추가하고,코드 상에서 만약 재고가 0이면 delYn=True 로 바꾼다 이런 경우일 것 같은데 제가 생각한게 맞을까요? 단일 연산으로도 정합성을 유지할 수 있는데 왜 stock을 다시 저장하는지 모르겠습니다
-
해결됨앨런 Swift Concurrency for Swift 6 (Part-2)
18강 NSCache 예시 질문
안녕하세요!18강 전체적으로 cache 에 값을 세팅하기 전후로 lock 이나 semaphore 등을 이용해서 GCD 에서 thread safe 를 구현하는 방법에 대한 예시를 들어준것 확인했습니다이때 removeAll() 의 앞뒤로는 따로 처리가 되어있지않아서, 정말 필요가 없어서 작성되어있지 않은건지, 아니면 단순 예시라서 여기까지는 적용하지 않은건지 궁금합니다func clearAll() { cache.removeAll() } 두번째로, 이건 주제와 좀 동떨어진 질문이긴한데요..! (혹시 강의 성격과 너무 벗어났다 싶으면 무시해주세요!)예시를 NSCache 로 들어주셨는데, NSCache 문서에 보면 캐시를 직접 잠그지 않고도 다양한 스레드에서 캐시에 항목을 추가, 제거 및 쿼리할 수 있다고 나와있는걸 확인했습니다.You can add, remove, and query items in the cache from different threads without having to lock the cache yourself즉, 문서를 통해 자체적으로 thread safe 하게 뭔가를 하고 있구나..를 유추할 수 있기 때문에 (내부적으로는 NSLock 을 사용하고 있긴하지만요) 이럴때는 저희쪽에서 @unchecked Sendable 만 사용해도 무방할까요?하지만 이런 문서 등을 확인하지 않는 이상 정확히 NSCache 가 thread safe 하게 뭔가를 처리한다는걸 확인할 수 없기 때문에, 예시처럼 @uncheked Sendable 명시와 동시에 자체적으로 semaphore 나 lock 을 걸어줘야하는건지..? 앨런님은 어떻게 생각하시는지 궁금합니다!감사합니다~
-
해결됨앨런 Swift Concurrency for Swift 6 (Part-2)
Task 클로저 내 `non-Sendable` 값 타입 접근 시, 캡처 리스트가 정의된 Task 순서에 따른 컴파일러 에러 차이
12강 16분 즘에, Task 의 클로저에 value type 의 프로퍼티를 캡처 리스트로 명시하면 아래와 같은 코드에서는 에러가 나지 않는다고 되어있습니다.struct ValueCounter { var value = 0 mutating func increment() -> Int { value = value + 1 return value } } func test() { var valueCounter = ValueCounter() Task { print(valueCounter.increment()) print(valueCounter.value) } Task { [valueCounter] in var newValueCounter = valueCounter print(newValueCounter.increment()) print(newValueCounter.value) } }하지만 제가 Xcode 26.0.1 에서 확인했을때는 해당 코드의 첫번째 Task 에서 다음과 같은 컴파일 에러가 발생했습니다Sending value of non-Sendable type '() async -> ()' risks causing data races이에 추가로 이것 저것 확인해보다가, 아래와 같이 캡처 리스트를 사용하는 Task 를 먼저 작성하면, 에러가 발생하지 않는것을 확인했습니다.// 캡처 리스트 사용하는 Task 순서 변경하니 정상 func test2() { var valueCounter = ValueCounter() Task { [valueCounter] in var newValueCounter = valueCounter print(newValueCounter.increment()) print(newValueCounter.value) } Task { print(valueCounter.increment()) print(valueCounter.value) } }이와 같은 현상을 어떻게 설명할 수 있을지 궁금합니다.첫번째 예시의 두번째 Task 에서는 [valueCounter] in 으로 현재 값을 캡처하려고해도, 이미 첫번째로 정의된 Task 에서 valueCounter.increment() 를 호출하면서 다른 스레드 (편의상) 에서 값을 변경하고 있기 때문에, 동일 시점에 딱 한개의 쓰레드에서의 접근이 깨져서 이런 에러가 발생하는 걸까요? (그렇다기엔 에러 위치는 첫번째 Task 정의에서 떠서... 아닌가 싶기도하고요..)두번째 예시의 첫번째 Task 에서는 캡처 리스트로 값을 캡처해서 valueCounter.increment() 를 호출하고, 두번째 Task 는 valueCounter.increment() 를 하려고해도 이 시점에서 valueCounter 를 참조하고 있는건 이곳 뿐이기 때문에 (첫번째 Task 에서는 캡처해서 사용), 동일 시점에 딱 한개의 쓰레드에서의 접근이 보장되어서 에러가 발생하지 않는걸까요? 결과를 기준으로 나름대로 고민을 해봤는데, 어쨌든 다 추측이라서.. 혹시 이와 같은 현상을 어떻게 이해하면 될지 궁금합니다감사합니다.
-
해결됨앨런 Swift Concurrency for Swift 6 (Part-1)
Task 의 default 우선순위 문의 (utility vs medium)
안녕하세요 3강 19:34 쯤에 Task 의 default 우선순위를 utility 로 말씀주셨는데, 제가 확인해봤을때는 medium 인 듯해서.. medium 이 맞을까요?Task.detached { print(Task.currentPriority) } // TaskPriority.mediumTaskPriority 의 구현부를 볼때도 default 가 medium 으로 되어있는것 같구요! @available(*, deprecated, renamed: "medium") public static let `default`: TaskPriority별로 중요한건 아니구, 나중에 한번 더 언급해주실거라고 하셔서 1부를 끝까지 들어봤는데, 별도로 말씀주시는 내용이 없는 듯 하여 가볍게 질문드립니다~감사합니다
-
미해결파이썬 동시성 프로그래밍 : 데이터 수집부터 웹 개발까지 (feat. FastAPI, async, await)
대규모 크롤링 시 동시 요청 수 제어 방법
asyncio.gather()를 사용해 여러 요청을 동시에 처리하는데, 실제 프로덕션 환경에서는 어떻게 다루는지 궁금합니다.예를 들어, 페이지를 1,000개 크롤링하거나 이미지를 수천 장 다운로드할 때 서버에 부하가 생기거나 IP 차단 같은 문제가 발생할 것 같습니다.해결 방법으로 동시 요청 수를 제한하는 게 좋을까요? 만약 그렇다면 적절한 동시성 수준(5개? 10개? 50개?)은 어떤 기준으로 결정하나요?
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
runnable 질문
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]섹션 3에서 runnable를 인터페이스로 불러서 사용할 때 static으로 정의하는 이유가 있나요? 그리고 간간히 왜 이거는 생성자를 받아오지 않고 바로 써야 하는지, 이건 왜 static을 써야 하는지 등등의 의문이 드는데 제가 자바에 대한 이해가 부족해서 그런 걸까요? ㅜㅜ 중급편 내용이 아는 내용이라 건너뛰었는데 중급도 수강하는게 맞을까요?
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
자바가 아닌 다른 언어에서도
동작원리자체는 동일할까요?닷넷에서 테스트코드 작성해도 동일할지 궁금합니다.
-
미해결재고시스템으로 알아보는 동시성이슈 해결방법
낙관적락vs. 레디스락
충돌 빈도가 낮지만 피크 타임에 스파이크가 있는 서비스라면, “낙관적 락+재시도”와 “레디스 락” 중 어떤 구성이 유지보수/비용/성능 면에서 유리한지 궁금합니다
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
메모리 가시성 문제가 발생하는 이유
멀티스레드 환경에서 메모리 가시성 문제가 발생하는 이유를, CPU 캐시와 메인 메모리 간의 데이터 갱신 시점 차이 때문이라고 이해했습니다.그렇다면 이 현상은 하드웨어 수준의 문제로 봐야 할까요, 아니면 JVM의 메모리 관리 방식이 영향을 주는 걸까요?또한, 이런 문제가 자바가 컴파일 언어이기 때문에 발생하는지도 궁금합니다.
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
데몬스레드가 어떨 때 사용이 되는지 궁금합니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]데몬스레드의 특징은 이해했는데, 어떨 때 사용이 되는 건지 궁금합니다. 그리고 현업에서도 보통 데몬 스레드를 사용할 일이 있나요?
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
Future.cancel() 취소를 사용하는 예가 궁금합니다.
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]여기에 질문 내용을 남겨주세요. 안녕하세요! 강의 잘 듣고 있는와중에 Future 관련 내용을 보다가 궁금한 점이 생겨서 질문 남깁니다. cancel() 기능이 필요한 실제 사례가 어떤 것이 있을까요?Future.cancel() 을 통해 실행을 취소시킬 수도 있다는 것은 이해가 됐습니다. 그런데 cancel() 기능이 필요한 실제 사례가 뭐가 있을지가 연상이 잘 안됩니다.실제로 작업을 수행하다가 취소 처리를 해야하는 경우가 일단 뭐가 있을지 궁금합니다.그냥 생각이 드는 건 특정 시간 제한이 지나서인데, 이건 get에 시간제한을 둬서 TimeoutException 하는 걸로 충분할 것 같아서요. cancel(false) 로 취소는 하되 과정은 수행하도록 내버려두는 케이스는 어떤 경우를 위해 있는건가요?아예 interrupt로 취소를 시키는 경우는 막상 예시가 떠오르진 않지만 논리적으로 이해가 갑니다. 어떤 작업을 수행하다가 특정 케이스에서는 필요가 없어져서 취소시킬 수 있겠다 싶습니다. 그런데 cancel(false) 로 취소는 하되 그 과정을 수행하도록 내버려둘 필요가 있나 싶어서요.어차피 cancel을 하면 true/false 어떤걸 넘겨줘도 get 하면 exception이 발생하면서 결과값을 못 얻는데 수행을 하게 내버려 둘 필요가 없을 것 같은데 어떤 경우를 위해 이렇게 구현이 되어 있는 건지 궁금합니다.
-
미해결자바 동시성 프로그래밍 [리액티브 프로그래밍 Part.1]
멀티스레드 단일스레드
멀티스레드와 단일스레드 구조를 선택할 때 어떤 기준으로 결정하나요? 단순히 성능만이 아니라, 트레이드오프 측면에서 고려할 부분도 있을 것 같아 질문드립니다.
-
해결됨스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판
락 오래 점유 시 장애 발생 가능성 질문
9:55 쯤에락을 오래 점유하면 발생하는 문제는 치명적이고 다양하다.리소스 고갈 등으로 인해 장애가 발생할 수 있는 것이다.지식공유자님께서는 오래 점유하는 상황에서 겪으셨던 문제가 있었나요?좋아요라는 게, 네트워크 문제가 아닌 이상 빠르게 끝날 처리인데, 혹시 좋아요 말고도 (다른) 쓰기 상태에서 락을 오래 점유하고 있을 때 어떤 문제를 겪으셨는지, 어떻게 해결하셨는지 러프하게라도 말씀해 주시면 감사드리겠습니다!! 감이 잘 안 와서 궁금해서 질문드립니다.
-
해결됨김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
synchronized 와 인스턴스의 lock
[질문 내용]이 부분을 보면 synchronized 메서드를 호출하려면 인스턴스의 lock이 필요하다고 되어잇는데, 헷갈리는 부분이 있습니다인스턴스는 메서드 단위가 아닌, 클래스 단위로 존재하는거라고 알고 있는데, 그러면 지금 synchronized 된 메서드 하나를 호출하면 해당 클래스 전체에 Lock 이 발생한다(다른 스레드는 접근하지 못한다)는 개념으로 이해가 되는데 이렇게 동작하는게 맞는건지 궁금합니다
-
미해결재고시스템으로 알아보는 동시성이슈 해결방법
안녕하세요. 레디슨 질문있습니다..!!
안녕하세요. 강의 잘 듣고있습니다.강의를 듣다보니 실무에서는 어떤식으로 waitTime, leaseTime을 정하는지 궁금해서 질문드립니다.강사님께서는 어떤 테스트와 어떤 생각으로 waitTime, leaseTime을 정하시나요?
-
미해결김영한의 실전 자바 - 고급 1편, 멀티스레드와 동시성
synchronized 키워드만으로 메모리 가시성이 해결되는 이유가 궁급합니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]synchronized 키워드를 사용하면 내부적으로 캐시 메모리에 있는 데이터를 메인 메모리에 값을 동기화 시켜주는 걸까요?