ScheduledThreadPoolExecutor, Java 5'te, herhangi bir yakalanmamış istisna durumunda felakete yol açan tek iş parçacığı sonlandırması sorununa yönelik, güçlü ve iş parçacığı güvenli bir alternatif olarak java.util.Timer için tanıtılmıştır. Zamansal anomali, periyodik bir görevin yürütme süresinin aralığını aştığında ortaya çıkar ve içsel ScheduledFutureTask uygulamasından kaynaklanır; burada periyot, pozitif değerlerin sabit oran anlamını (mutlak zaman programlaması) ve negatif değerlerin sabit gecikme anlamını (göreli zaman programlaması) belirttiği bir long olarak saklanır. Bir periyodik görevin yürütme süresi aralığını aştığında, sabit oran, görevleri dinlenmeden art arda yürütmeye çalışarak programı korumaya çalışır ve bu da kayma ve potansiyel kaynak tüketimine yol açar; oysa sabit gecikme, her tamamlamadan sonra zorunlu bir duraklama ekleyerek, sistemin kararlılığını sağlamak için zamansal yer değiştirmeye izin verir.
Beş saniyede bir sunucu vital verilerini toplayan bir dağıtık sağlık izleme platformu işletiyorduk ve bu durumda ScheduledThreadPoolExecutor ile scheduleAtFixedRate yapılandırması kullanıyorduk. Kritik bir veritabanı bozulması sırasında, metrik toplama sorguları otuz saniye sonra zaman aşımına uğramaya başladı, ancak yürütücü, gecikmeden bağımsız olarak mutlak programına göre her beş saniyede bir yeni görev göndermeye devam etti ve bu, iş kuyruğunun sınırsız şekilde büyümesine neden oldu ve OutOfMemoryError tehdidi oluşturdu.
Yaklaşan sistem çöküşünü önlemek ve izlenebilirliği sürdürmek için birkaç mimari çözüm değerlendirildi. Toplanan iş yükünü karşılamak için havuz boyutunu artırmak anında reddedildi çünkü bu, zaten başarısız olan veritabanı üzerindeki baskıyı artırırdı, kurtarma sırasında bir boğaz problemi yaratır ve sınırsız kuyruk büyümesi ve iş parçacığı çoğalması nedeniyle bellek tüketimini hızlandırırdı. Veritabanı sağlıklı olmadığında yürütmeyi atlamak için çalıştırılabilir içine bir devre kesici uygulamak operasyonel olarak geçerli kabul edildi, ancak iş mantığına önemli bir karmaşıklık ekledi ve eşzamanlı iş parçacıkları arasında ince senkronizasyon tehlikeleri ve test zorlukları getiren paylaşılan değişken durumu gerektiriyordu. Sonunda scheduleWithFixedDelay'ye geçiş, ek kod karmaşıklığı olmadan içsel geri basınç sağladığı için seçildi: Görevler otuz saniye sürdüğünde, bir sonraki yürütme tamamlamadan sonra ilave beş saniye bekledi ve isteklerin doğal olarak yönlendirilmesine ve veritabanının toparlanmasına izin verdi, böylece kaynak tüketimini önledi. Sistem, çökme olmadan olay sırasında stabil hale geldi, ancak izleme panelleri geçmiş verilerdeki düzensiz zamansal boşlukları ortaya çıkardı ve bu da eğilim analizini karmaşıklaştırdı; bu durum, zincirleme arıza ve tam veri kaybı alternatifine kıyasla kabul edilebilir olarak değerlendirildi.
İki görevin yürütme zaman damgaları aynı olduğunda, içsel DelayedWorkQueue sıralamayı nasıl korur ve bu yüksek verimli senaryolarda belirgin zamanlama adaletsizliğine neden olabilir?
DelayedWorkQueue, görevleri bir time alanına göre sıralamakta olan ikili bir yığın olup, bu alan bir sonraki yürütme zaman damgasını temsil eder. Zaman damgaları çakıştığında, sunum zamanında atanan monoton olarak artan bir sequenceNumber alanına geri döner; bu da daha önce gönderilen görevlere öncelik verir. Bu FIFO eşitlik bozucu faktör, havuzun yetersiz olması durumunda uzun süreli periyodik görevlere açlık yapabilir; çünkü yürütücü, yığından en kısa bekleme süresine sahip görevi sürekli seçerken, gecikmeli görev kuyrukta gömülü kalır ve sezgisel yuvarlak-robin beklentilerini ihlal eder.
Neden ScheduledThreadPoolExecutor, bir çalıştırılabilir nesnesi yakalanmamış bir istisna attıktan sonra diğer planlı görevleri işlemeye devam eder, oysa java.util.Timer, tüm zamanlama iş parçacığını sonlandırır?
Timer, herhangi bir yakalanmamış istisna durumunda ölen tek bir arka plan iş parçacığı kullanırken, ScheduledThreadPoolExecutor, her görev yürütmesinin FutureTask.run() aracılığıyla gerçekleştiği iş parçacığı havuzu mimarisini kullanır. İstisnalar yakalanır ve ScheduledFuture'nin çıktısı olarak saklanır; ancak, işçi iş parçacığı, DelayedWorkQueue'den sonraki görevleri işlemek için havuza zarar görmeden geri döner. Özellikle periyodik görevler için, runAndReset() bir istisna nedeniyle yanlış dönerse, görev yeniden programlanmaz ancak iş parçacığı hala bekleyen diğer zamanlamaları işlemeye devam eder, bu da izolasyon ve dayanıklılık sağlar.
remove(Runnable) çağrıldığında, neden yürütücü, yöntem true döner dönmez bir görevi yürütmeye devam edebilir ve dinamik iptali karmaşıklaştıran belirli kimlik eşleştirme davranışı nedir?
remove() yöntemi, ilişkili ScheduledFuture'yi iptal etmeye ve DelayedWorkQueue'den kaldırmaya çalışır, ancak zaten aktif yürütme durumuna geçmiş bir görevi kesintiye uğratamaz. Ek olarak, yürütücü, gönderilen çalıştırılabilirleri ScheduledFutureTask nesneleri içinde sarmalar, bu nedenle remove(), çağrıcı tarafından geçirilen ham Runnable'a karşı bu sargı örnekleri ile kimlik karşılaştırması yapar. Geliştiricilerin, güvenilir bir şekilde görevleri iptal etmek için zamanlama yönteminin döndürdüğü ScheduledFuture'yi saklamaları gerekir; çünkü orijinal çalıştırılabilirin geçerli durumunu kaldırmak için geçişinin genellikle iç sargı ile referans eşitsizliği nedeniyle başarısız olur.