Thread.interrupt() bir Selector.select() içinde engellenen bir iş parçacığına hedef alındığında, seçici hemen boş bir seçilmiş anahtar kümesiyle dönerken iş parçacığının kesinti bayrağını ayarlar. Bu, çağıran kodun dönen değere dayanarak kanalın I/O için hazır olup olmadığını veya dönüşün yalnızca kesinti sinyalini yansıtıp yansıtmadığını belirleyememesi nedeniyle mimari belirsizlik yaratır. Selector.wakeup()'ın aksine, bu seçici kesinti durumunu etkilemeden seçiciyi engellenmeden çıkarırken, bir kesinti, kapatma sinyalini I/O olaylarıyla birleştirir. Sonuç olarak, sağlam uygulamalar, gerçek hazır durumu ile yanıltıcı uyanmayı ayırt etmek için Thread.interrupted()'u açıkça kontrol etmeli veya paylaşılan bir volatile durum değişkenine danışmalıdır; böylece CPU yoğun döngülerden kaçınılmalıdır.
Yüksek verimli bir Java NIO kapısıyla piyasa verisi beslemelerini işleyen bir senaryoyu düşünün; burada özel bir iş parçacığı, SelectionKey olaylarını işçi iş parçacıklarına iletmek için Selector.select() üzerinde engellenir. Sıfır kesinti süresiyle dağıtım sırasında, orkestrasyon katmanı bu seçici iş parçacığını, havada olan işlemleri tamamladıktan sonra operasyonları zarif bir şekilde durdurmak için sinyal vermelidir.
İlk uygulama, sonlandırmayı sinyal vermek için Thread.interrupt() kullandı. Bu, select()'i başarılı bir şekilde engellemeyi kaldırdı, ancak kritik bir canlı kilit oluşturdu: select() sıfır anahtar döndürdü, bu da olay döngüsünün sürekli olarak tam CPU kullanımıyla dönmesine neden oldu. İş parçacığı, I/O etkinliğinin var olduğunu varsayarak, tüm kayıtlı kanallarda engellemeyen okumalar yapmaya çalıştı, hiçbiri hazır bulunamadı ve hemen select()'i yeniden çağırdı; bu, kalan kesinti bayrağı nedeniyle hemen döndü.
Önerilen bir alternatif, süresiz engellemeyi select(100) ile birlikte bir volatile boolean kapanma bayrağı ile değiştirdi. Bu strateji, engellenme süresini sınırlayarak CPU doygunluğunu önledi ve Thread.interrupt() kullanmadan sonlandırma sinyalleri için basit bir anketleme mekanizması sundu. Ancak, kapanma tespitinde bekleme süresine kadar belirleyici gecikmeler getirdi ve zirve yük altında bağlam değişiklikleri maliyetini %20 artırarak yüksek frekanslı işlemler için verimliliği azalttı.
Başka bir aday çözüm, tamamen bir kapanma kancası tarafından tetiklenen Selector.wakeup() kullandı ve kesinti anlamsallarını tamamen ortadan kaldırdı. Bu, boş anahtar kümesi belirsizliği olmaksızın anında engellemeyi sağladı ve acil durumları için kesinti bayrağını korudu. Bununla birlikte, wakeup()'ın anahtarları işleme sürecinde, kesici iş parçacığı bloke olmadan çalışırken yürütülmesi durumunda "kaybolan uyanma" yarış koşulu riski taşıyordu ve bu da select()'in sonsuz bir şekilde engellenmesine neden olabiliyordu, bir sonraki I/O olayı gelene kadar.
Son tasarım, dikkatli bir happened-before semantiği kullanarak Selector.wakeup() ile bir volatile AtomicBoolean kapanma bayrağını senkronize etti. Kapanma sırası, bayrağı atomik olarak ayarladı ve ardından wakeup()'ı çağırdı; olay döngüsü select() dönüşü hemen bayrağı kontrol etti ve anahtarların mevcudiyetine bakılmaksızın kapanma talep ediliyorsa temiz bir şekilde çıkış yaptı. Bu, CPU döngüsünü ortadan kaldırdı, kapanma başlatılana kadar tam I/O verimliliğini sürdürdü ve kesinti durumu kontrollerine dayanmayarak 50 ms'den az kapanma gecikmesi elde etti.
Kapı, döngüsel dağıtımlar sırasında sıfır hatalı istekle 10,000'den fazla eşzamanlı bağlantıyı başarılı bir şekilde işledi. CPU kullanımı, kapanma sıraları boyunca baz seviyelerde kaldı ve mimari, I/O olaylarının işlenmesi ile yaşam döngüsü yönetim sinyalleri arasında net bir ayrım sağladı.
Thread.interrupted() Thread.isInterrupted()'den nasıl farklıdır ve bayrağın temizlenmesi iç içe geçmiş temizleme rutinlerinde neden tehlikeler yaratır?
Thread.interrupted(), mevcut iş parçacığının kesinti durumunu kontrol eder ve temizlerken, Thread.isInterrupted() bayrağı değişiklik yapmadan sorgular. Seçici döngülerde, geliştiriciler genellikle Thread.interrupted()'ı kapanma sinyallerini algılamak için iş parçacığının döngüden çıkma niyetiyle çağırır. Ancak, takip eden temizleme kodu, channel.close() gibi engelleyen I/O işlemleri gerçekleştirirse veya CountDownLatch kapanışını beklerse, bu işlemler daha önce temizlenmiş kesinti durumunu göremez, bu nedenle başlangıçta talep edilen kapanma isteğine yanıt vermek yerine sonsuz bir şekilde blokta kalabilir.
Kapatma durumunda Selector.select() neden normal olarak sıfır anahtar döndürüyor, InterruptedException fırlatmıyor ve bu ne tür bir kontrol akışı belirsizliği yaratıyor?
Object.wait() veya Thread.sleep() gibi engelleyen yöntemlerin aksine, Selector.select() InterruptedException'i beyan etmez ve Thread.interrupt() çağrıldığında hemen sıfır seçilen anahtar ile döner. Bu tasarım seçimi, tesadüfen sıfır anahtar döndürebilecek gerçek I/O hazır olmayı kesinti sinyalleriyle birleştirir ve uygulamaların "hiçbir kanal hazır değil" ile "kapatma istemi var" arasında ayırt etmek için açık durum kontrolleri uygulamasını zorunlu kılar. Adaylar genellikle bu ayrımı gözden kaçırır, sıfır anahtarın canlı kilidi veya hemen yeniden denemeyi ima ettiğini varsayıp döngüler yazarlar; bu da seçicinin yalnızca bir kesinti bayrağına yanıt vermek üzere olduğu durumlarda CPU doygunluğuna neden olur.
Selector.wakeup() neden paylaşılan değişkenler için bellek görünürlük garantisi sağlamaz ve bu neden kapanma bayrakları için volatile veya senkronize anlamsallara ihtiyaç duyar?
Selector.wakeup() seçici iş parçacığını atomik olarak engellemeyi kaldırsa da, uyandırma çağrısı ile engellenmeyen iş parçacığı tarafından paylaşılan kapanma değişkenlerinin sonraki okunması arasında bir happens-before ilişkisi kurmaz. Sonuç olarak, kapanma bayrağını volatile olarak tanımlamadan veya onu senkronize bloklar içinde erişmeden, seçici iş parçacığı, wakeup() yürütüldükten sonra bile, tazelenmemiş bir önbellek değerini (false) gözlemleyebilir ve bu da onu tekrar select()'e sokarak mantıksal kapanmanın başlatılması durumunda sonsuz bir şekilde engellenmesine neden olur. Bu ince Java Bellek Modeli etkileşimi, yalnızca wakeup()'ın güvenilir bir çapraz iş parçacığı iletişimi için yetersiz olduğu anlamına gelir; durum değişikliklerinin görünürlüğünü sağlamak için uygun senkronizasyonla eşleştirilmelidir.