[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]synchronized 이전 강의에서 join 을 활용하여 순서를 쓰레드의 순서를 보장하여 실행하는 방법에 대해 배웠습니다. 만약 동시에 같은 값에 대해 접근하는 것이 문제 라고 가정 할 경우 join 을 활용하여 특정 쓰레의 종료 이전 까지 다음 쓰레드 를 시작하는 것을 막는 다면 해결할수 있는 문제가 아닌가 생각합니다.예를들어 다음과 같이 t1.join() 을 사용하면 t1 의 쓰레드가 종료 이전 까지는 t2 는 대기 상태가 될 것이고 t1 에서 최종 결과가 나오기 전까지는 t2 는 실행하지 못할 것 입니다.public class BankMain { public static void main(String[] args) throws InterruptedException { //BankAccount account = new BankAccountV1(1000); BankAccount account = new BankAccountV1(1000); Thread t1 = new Thread(new WithdrawTask(account, 800), "t1"); Thread t2 = new Thread(new WithdrawTask(account, 800), "t2"); t1.start(); t1.join(); sleep(500); log("t1 state :"+t1.getState()); log("t2 state :"+t2.getState()); t2.start(); //t2.join(); log("최종 잔액 : "+account.getBalance()); } }

=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]메모리 가시성 문제 가 발생하는 이유는 쓰레드가 공유 된 runFlag 값에 대해 반영이 않되어서 발생하는 문제라고 설명을 해주셨습니다. 예를들어 main 쓰레드에서는 false 를 true 로 변경하였으나 work 쓰레드에서는 해당 값이 변경되었는지 모르기 때문에 계속 동작하는 상태 입니다. 여기서 이해가 않가는 부분이 모든 프로그램은 보조기억 장치에서 실행을 하고 실행에 필요한 변수가 값 들은 모두 ram 과 같은 주 기억 장치에 저장되고 사용되는 걸로 알고 있습니다.  그렇다면 이 과정에서 쓰레드는 캐시메모리가 아닌 주기억 장치에서 값을 읽어서 사용해야 합니다. 지금 과정으로 설명된 것을 이해 하면 주기억 장치 또한 단순히 값을 저장하는 것 뿐이고 실제로는 캐시 메모리에서 한번더 데이터를 저장하고 cpu 는 캐시메모리에 접근하여 데이터를 연산한다고 이해 했습니다. 맞을까요? 

18분 55초 쯤 예시를 보여주시면서/// 2) (액터 외부) 동기 코드가 (일반) 비동기 코드에서 불려지면.. 어떤 (컨텍스트에 해당하는) 작업(Task) 내부에서 실행됨 ===> Task 격리 ​ func readAny(with books: [Book]) async {    if let book = books.randomElement() {        readBook(with: book)    } } ​ Task {    let account = LibraryAccount(idNumber: 1)     /// 액터    let books = await account.booksOnLoan         /// 액터내부의 (상태)값 가져오기 (Sendable타입)        await readAny(with: books)                    /// 액터 외부에서 실행 (일반적으로 이런 구현은 옳지 않음) }위와 같은 코드에서 Task 가 3번 스레드에서 돌아가고 있었다고 치면, account.booksOnLoan 을 가져오는건 2번 스레드로 갈 수 있다고 쳐도, await readAny(with:) 는 다시 Task 와 동일한 3번 스레드에서 돌아가게 될거다! 라고 말씀을 주셨는데요사실 nonisolated async func 인 readAny 를 await 로 호출을 하는 순간, 해당 함수는 Task 의 스레드는 무관한게 아무 스레드에서나 돌아갈 수 있다고 생각을 했습니다 (실제로 Task 를 mainActor context 로 두고 해당 코드를 돌려봐도 readyAny 는 main 에서 돌아가지 않았구여!)이해 편의상 돌려서 설명을 주시건가??? 생각이 들지만 혹시 정확히 어떤 의미로 요렇게 말씀을 주신건지 궁금합니다~감사합니다저장

안녕하세요 앨런님! 19강에서 actor 를 이해 편의상 "특정한 하나의 스레드에서만 실행"되는 것처럼 그림을 첨부해주셨는데요 (물론 설명으로는 한번에 하나씩 실행되는건 맞지만 스레드를 특정할 수는 없다" 라고 말씀주셨지만요)그러면 이해 편의상이 아니라, 좀 더 정확하게는 제가 이해한 내용이 맞을지 한번 확인 부탁드려도 될까요?항상 좋은 강의 감사합니다.   기본적으로 actor 의 실행 스레드는 고정되어있지 않음Actor 의 메서드나 데이터에 접근하면 serial executor 에 작업이 쌓일 것이때 actor 는 선입 선출로 동작하지 않으므로, 우선 순위에 따라 실행 순서는 달라질 수 있음Actor 의 작업이 실행될때 어느 스레드에서 실행할건지는 상관없고 중요하지도 않음. 한 작업이 끝나고 나면, serial executor 에서 대기하고 있던 작업은 어느 스레드에서든 heap 에 저장된 데이터 읽어서, 그 데이터 기반으로 작업하면 되는 것.중요한건 데이터 경쟁이 발생하지 않게 serial executor 에 넣어서 actor 관련 작업은 한번에 하나의 스레드에서만 돌게 하는 매커니즘

1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]안녕하세요.Future를 거치는 SumTaskMainV2에서 future2.get()이 future1.get() 실행 후 task1의 call() 완료를 기다리지 않고 바로 실행되는 것을 콘솔 로그로 확인 가능했는데요.그렇다면 Future를 거치지 않고 결과를 반환한다 가정할 때, task2가 task1 완료를 기다린 후 수행된다고 나와있는데, "Future는 한 스레드 작업의 future1.get() 실행 후, 다른 스레드의 작업 future2.get()은 future1의 call() 완료까지 기다리지 않는 기능이 있다"이렇게 이해해도 될까요?

안녕하세요. 저는 daemon=True 해도 서브가 모두 돌고 끝납니다. 무슨 이유가 있을까요?  # 스레드 실행 함수 def thread_func(name, d): logging.info('Sub-Thread %s: starting', name) for i in d: print(i) logging.info('Sub-Thread %s: finished', name) ... # 함수 인자 확인 # daemon : default False x = threading.Thread(target=thread_func, args=('First', range(20000)), daemon=True) y = threading.Thread(target=thread_func, args=('Second',range(10000)), daemon=True)19:16:32: Main-Thread: all done012...1999919:16:32: Sub-Thread Second: finished19:16:32: Sub-Thread First: finished

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 기반 테스트만으로는 실제 운영 환경(수십만 건의 요청)에서 발생할 수 있는 동시성 이슈를 완전히 검증하기 어렵다는 지적을 받은 적이 있습니다.혹시 이러한 한계를 보완할 수 있는 다른 검증 방법이나 접근 방식이 있을까요?

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을 다시 저장하는지 모르겠습니다

안녕하세요!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 을 걸어줘야하는건지..? 앨런님은 어떻게 생각하시는지 궁금합니다!감사합니다~

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 에서는 캡처해서 사용), 동일 시점에 딱 한개의 쓰레드에서의 접근이 보장되어서 에러가 발생하지 않는걸까요? 결과를 기준으로 나름대로 고민을 해봤는데, 어쨌든 다 추측이라서.. 혹시 이와 같은 현상을 어떻게 이해하면 될지 궁금합니다감사합니다.

안녕하세요 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부를 끝까지 들어봤는데, 별도로 말씀주시는 내용이 없는 듯 하여 가볍게 질문드립니다~감사합니다

asyncio.gather()를 사용해 여러 요청을 동시에 처리하는데, 실제 프로덕션 환경에서는 어떻게 다루는지 궁금합니다.예를 들어, 페이지를 1,000개 크롤링하거나 이미지를 수천 장 다운로드할 때 서버에 부하가 생기거나 IP 차단 같은 문제가 발생할 것 같습니다.해결 방법으로 동시 요청 수를 제한하는 게 좋을까요? 만약 그렇다면 적절한 동시성 수준(5개? 10개? 50개?)은 어떤 기준으로 결정하나요?

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]섹션 3에서 runnable를 인터페이스로 불러서 사용할 때 static으로 정의하는 이유가 있나요? 그리고 간간히 왜 이거는 생성자를 받아오지 않고 바로 써야 하는지, 이건 왜 static을 써야 하는지 등등의 의문이 드는데 제가 자바에 대한 이해가 부족해서 그런 걸까요? ㅜㅜ 중급편 내용이 아는 내용이라 건너뛰었는데 중급도 수강하는게 맞을까요?

동작원리자체는 동일할까요?닷넷에서 테스트코드 작성해도 동일할지 궁금합니다.

충돌 빈도가 낮지만 피크 타임에 스파이크가 있는 서비스라면, “낙관적 락+재시도”와 “레디스 락” 중 어떤 구성이 유지보수/비용/성능 면에서 유리한지 궁금합니다 

멀티스레드 환경에서 메모리 가시성 문제가 발생하는 이유를, CPU 캐시와 메인 메모리 간의 데이터 갱신 시점 차이 때문이라고 이해했습니다.그렇다면 이 현상은 하드웨어 수준의 문제로 봐야 할까요, 아니면 JVM의 메모리 관리 방식이 영향을 주는 걸까요?또한, 이런 문제가 자바가 컴파일 언어이기 때문에 발생하는지도 궁금합니다.

 학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]데몬스레드의 특징은 이해했는데, 어떨 때 사용이 되는 건지 궁금합니다. 그리고 현업에서도 보통 데몬 스레드를 사용할 일이 있나요?