Java 11 ve ötesine geçme nedenleri

Soru, Java 11 veya sonraki bir sürüme geçmeniz gerekip gerekmediği değil, ne zaman olduğudur. Önümüzdeki birkaç yıl içinde Java 8 artık desteklenmeyecektir ve kullanıcıların Java 11 veya sonraki sürümlere geçmesi gerekecektir. Java 11'e geçmenin avantajları olduğunu savunuyoruz ve ekipleri bunu en kısa sürede yapmaya teşvik ediyoruz.

Java 8'den bu yana yeni özellikler eklendi ve geliştirmeler yapıldı. API'de fark edilebilir eklemeler ve değişiklikler vardır ve başlatma, performans ve bellek kullanımını geliştiren geliştirmeler vardır.

Java 11'e geçiş

Java 11'e geçiş adım adım yapılabilir. Kodun Java 11'de çalıştırılacak Java modüllerini kullanması gerekli değildir . Java 11, JDK 8 ile geliştirilen ve oluşturulan kodu çalıştırmak için kullanılabilir. Ancak, öncelikli olarak kullanım dışı API, sınıf yükleyicileri ve yansımayla ilgili bazı olası sorunlar vardır.

Microsoft Java Mühendislik Grubu, Java 8'den Java 11'e geçiş kılavuzuna sahiptir. Java Platformu, Standard Edition Oracle JDK 9 Geçiş Kılavuzu ve Modül Sisteminin Durumu: Uyumluluk ve Geçiş diğer yararlı kılavuzlardır.

Java 8 ile 11 arasında üst düzey değişiklikler

Bu bölüm Java sürüm 9 [1], 10 [2] ve 11 [3] sürümlerinde yapılan tüm değişiklikleri listelemez. Performans, tanılama ve üretkenlik üzerinde etkisi olan değişiklikler vurgulanır.

Modüller [4]

Modüller , sınıf yolu üzerinde çalışan büyük ölçekli uygulamalarda yönetilmesi zor olan yapılandırma ve kapsülleme sorunlarını giderir. Modül, Java sınıflarının, arabirimlerinin ve ilgili kaynakların kendi kendini açıklayan bir koleksiyonudur.

Modüller, yalnızca bir uygulamanın gerektirdiği bileşenleri içeren çalışma zamanı yapılandırmalarını özelleştirmeyi mümkün hale getirir. Bu özelleştirme daha küçük bir ayak izi oluşturur ve bir uygulamanın jlink kullanarak dağıtım için özel bir çalışma zamanına statik olarak bağlanmasına olanak tanır. Bu küçük ayak izi, mikro hizmet mimarisinde özellikle yararlı olabilir.

Dahili olarak, JVM sınıf yüklemeyi daha verimli hale getirecek şekilde modüllerden yararlanabilir. Sonuç, daha küçük, daha hafif ve daha hızlı başlayan bir çalışma zamanıdır. Modüller bir sınıfın gerektirdiği bileşenleri kodladığı için JVM tarafından uygulama performansını geliştirmek için kullanılan iyileştirme teknikleri daha etkili olabilir.

Programcılar için modüller, bir modülün hangi paketleri dışarı aktardığını ve hangi bileşenleri gerektirdiğini açık bir şekilde bildirerek ve yansıtıcı erişimi kısıtlayarak güçlü kapsüllemesi zorunlu kılmaya yardımcı olur. Bu kapsülleme düzeyi, bir uygulamayı daha güvenli ve bakımı kolay hale getirir.

Bir uygulama sınıf yolu kullanmaya devam edebilir ve Java 11'de çalıştırmak için gerekli bir koşul olarak modüllere geçiş yapmak zorunda değildir.

Profil oluşturma ve tanılama

Java Flight Recorder [5]

Java Flight Recorder (JFR), çalışan bir Java uygulamasından tanılama ve profil oluşturma verilerini toplar. JFR'nin çalışan bir Java uygulaması üzerinde çok az etkisi vardır. Daha sonra toplanan veriler Java Mission Control (JMC) ve diğer araçlarla analiz edilebilir. JFR ve JMC, Java 8'de ticari özelliklerdi ancak her ikisi de Java 11'de açık kaynaktır.

Java Görev Denetimi [6]

Java Mission Control (JMC), Java Flight Recorder (JFR) tarafından toplanan verilerin grafik görüntüsünü sağlar ve Java 11'de açık kaynaktır. Çalışan uygulama hakkında genel bilgilere ek olarak JMC, kullanıcının verilerde detaya gitmesine de olanak tanır. JFR ve JMC bellek sızıntıları, GC ek yükü, sıcak yöntemler, iş parçacığı darboğazları ve engelleyen G/Ç gibi çalışma zamanı sorunlarını tanılamak için kullanılabilir.

Birleşik günlüğe kaydetme [7]

Java 11, JVM'nin tüm bileşenleri için ortak bir günlüğe kaydetme sistemine sahiptir. Bu birleşik günlük sistemi, kullanıcının hangi bileşenlerin hangi düzeyde günlüğe kaydedileceklerini tanımlamasına olanak tanır. Bu ayrıntılı günlük, JVM kilitlenmelerinde kök neden analizi gerçekleştirmek ve üretim ortamındaki performans sorunlarını tanılamak için kullanışlıdır.

Düşük ek yük yığın profilleme [8]

Java yığın ayırmalarını örneklemek için Java Sanal Makine Aracı Arabirimi'ne (JVMTI) yeni API eklendi. Örneklemenin yükü düşüktür ve sürekli olarak etkinleştirilebilir. Yığın ayırma Java Flight Recorder (JFR) ile izlenebilirken, JFR'de kullanılan örnekleme yöntemi yalnızca yığın ayırmalarında çalışır. JFR uygulaması ayırmaları da kaçırabilir. Buna karşılık Java 11'de yığın örneklemesi hem canlı hem de ölü nesneler hakkında bilgi sağlayabilir.

Uygulama Performansı İzleme (APM) satıcıları bu yeni özelliği kullanmaya başlıyor ve Java Mühendislik Grubu, Azure performans izleme araçlarıyla olası kullanımını araştırıyor.

StackWalker [9]

Günlük kaydı sırasında, geçerli iş parçacığı için yığının anlık görüntüsünü almak sıklıkla kullanılır. Sorun, yığın izlemesinin ne kadarının günlüğe kaydedileceği ve yığın izlemesinin günlüğe kaydedilip kaydedilmeyeceğidir. Örneğin, bir yöntemden sadece belirli bir özel durumun yığın izini görmek isteyebilirsiniz. StackWalker sınıfı (Java 9'da eklendi) yığının anlık görüntüsünü verir ve programcıya yığın izlemesini kullanma konusunda ayrıntılı denetim sağlayan yöntemler sağlar.

Çöp toplama [10]

Java 11'de aşağıdaki çöp toplayıcılar kullanılabilir: Serial, Parallel, Garbage-First ve Epsilon. Java 11'de varsayılan çöp toplayıcı, Garbage First Çöp Toplayıcı (G1GC)'dir.

Eksiksiz olması için burada üç toplayıcı daha belirtilmiştir. Z Çöp Toplayıcısı (ZGC), duraklatma sürelerini 10 ms'nin altında tutmaya çalışan eşzamanlı ve düşük gecikmeli bir toplayıcıdır. ZGC, Java 11'de deneysel bir özellik olarak kullanılabilir. Shenandoah toplayıcısı, çalışan Java programıyla eşzamanlı olarak daha fazla çöp toplama gerçekleştirerek GC duraklatma sürelerini azaltan düşük duraklamalı bir toplayıcıdır. Shenandoah, Java 12'de deneysel bir özelliktir, ancak Java 11'e yönelik arka bağlantılar vardır. Eşzamanlı İşaretle ve Süpür toplayıcısı (CMS) kullanılabilir ancak Java 9'dan beri kullanım dışıdır.

JVM, ortalama kullanım örneği için GC varsayılanlarını ayarlar. Genellikle bu varsayılan değerlerin ve diğer GC ayarlarının, uygulamanın gereksinimlerine göre en iyi aktarım hızı veya gecikme süresi için ayarlanması gerekir. GC'nin düzgün ayarlanması, Microsoft Java Mühendislik Grubu'nun sağladığı GC, uzmanlık hakkında ayrıntılı bilgi gerektirir.

G1GC

Java 11'de varsayılan çöp toplayıcı, G1 çöp toplayıcıdır (G1GC). G1GC'nin amacı, gecikme süresi ile aktarım hızı arasında bir denge sağlamaktır. G1 çöp toplayıcısı, duraklatma süresi hedeflerini yüksek olasılıkla karşılayarak yüksek aktarım hızına ulaşmayı dener. G1GC, tam bellek toplama işlemlerinden kaçınmak için tasarlanmıştır; ancak, eşzamanlı toplama işlemleri belleği yeterince hızlı geri kazanamıyorsa, yedek olarak bir tam GC meydana gelecektir. Tam GC, genç ve karma koleksiyonlarla aynı sayıda paralel çalışan iş parçacığı kullanır.

Paralel GC

Paralel toplayıcı, Java 8'de varsayılan toplayıcıdır. Paralel GC, çöp toplama işlemini hızlandırmak için birden çok iş parçacığı kullanan bir verim toplayıcıdır.

Epsilon [11]

Epsilon çöp toplayıcısı bellek ayırmalarını yönetir ancak bellek geri kazanımı yapmaz. Yığın tükendiğinde JVM kapanır. Epsilon, kısa süreli hizmetler ve çöpsüz olduğu bilinen uygulamalar için kullanışlıdır.

Docker kapsayıcıları için iyileştirmeler [12]

Java 10'dan önce, bir kapsayıcıda ayarlanan bellek ve CPU kısıtlamaları JVM tarafından tanınmadı. Örneğin Java 8'de JVM varsayılan olarak temel konağın fiziksel belleğinin en büyük yığın boyutunu 1/4 olarak belirler. Java 10'dan başlayarak JVM, bellek ve CPU sınırlarını ayarlamak için kapsayıcı denetim grupları (cgroups) tarafından ayarlanan kısıtlamaları kullanır (aşağıdaki nota bakın). Örneğin, varsayılan en büyük yığın boyutu kapsayıcının bellek sınırının 1/4'dür (örneğin, -m2Giçin 500 MB).

JVM Seçenekleri, Docker kapsayıcısı kullanıcılarına Java yığını için kullanılacak sistem belleği miktarı üzerinde ayrıntılı denetim sağlamak için de eklendi.

Bu destek varsayılan olarak etkindir ve yalnızca Linux tabanlı platformlarda kullanılabilir.

Uyarı

Cgroup etkinleştirme çalışmalarının çoğu jdk8u191 itibarıyla Java 8'e geri aktarıldı. Diğer iyileştirmeler 8'e geri aktarılmayabilir.

Çok sürümlü jar dosyaları [13]

Java 11'de sınıf dosyalarının Java sürümüne özgü birden çok sürümünü içeren bir jar dosyası oluşturmak mümkündür. Çok sürümlü jar dosyaları, kitaplık geliştiricilerinin jar dosyalarının birden çok sürümünü göndermek zorunda kalmadan Java'nın birden çok sürümünü desteklemesini mümkün hale getirir. Bu kitaplıkların tüketicisi için, çok sürümlü jar dosyaları belirli jar dosyalarını belirli çalışma zamanı hedefleriyle eşleştirmek zorunda olma sorununu çözer.

Çeşitli performans geliştirmeleri

JVM'de yapılan aşağıdaki değişikliklerin performans üzerinde doğrudan etkisi vardır.

• JEP 197: Kesimli Kod Önbelleği [14] - Kod önbelleğini ayrı segmentlere böler. Bu segmentasyon, JVM bellek ayak izi için daha iyi denetim sağlar, derlenen yöntemlerin tarama süresini kısaltır, kod önbelleğinin parçalanma süresini önemli ölçüde azaltır ve performansı artırır.

• JEP 254: Dizeleri Sıkıştır [15] - Karakter kodlamasına bağlı olarak dizenin iç gösterimini karakter başına iki bayttan karakter başına bir veya iki bayt olarak değiştirir. Çoğu Dize ISO-8859-1/Latin-1 karakter içerdiğinden, bu değişiklik bir Dizeyi depolamak için gereken alan miktarını etkili bir şekilde yarıya indirmektedir.

• JEP 310: Uygulama Class-Data Paylaşımı [16] - Class-Data Paylaşımı, arşivlenmiş sınıfların çalışma zamanında belleğe eşlenmesine izin vererek başlatma süresini azaltır. Uygulama Class-Data Paylaşımı, uygulama sınıflarının CDS arşivine yerleştirilmesine izin vererek sınıf veri paylaşımını genişletir. Birden çok JVM aynı arşiv dosyasını paylaştığında bellekten tasarruf edilir ve genel sistem yanıt süresi iyileşir.

• JEP 312: Thread-Local El Sıkışmaları [17] - Genel bir VM güvenli noktası gerçekleştirmeden iş parçacıklarında geri çağırma yürütmeyi mümkün kılar ve bu da vm'nin genel güvenli nokta sayısını azaltarak daha düşük gecikme süresi elde etmesine yardımcı olur.

• Derleyici İş Parçacıklarının Gecikmeli Ayrılması [18] - Katmanlı derleme modunda, VM çok sayıda derleyici iş parçacığı başlatır. Bu mod, birçok CPU'ya sahip sistemlerde varsayılandır. Bu iş parçacıkları kullanılabilir bellek veya derleme isteklerinin sayısından bağımsız olarak oluşturulur. İş parçacıkları boşta olsalar bile (neredeyse her zaman) bellek tüketir ve bu da kaynakların verimsiz kullanımına neden olur. Bu sorunu gidermek için uygulama, başlatma sırasında her türden yalnızca bir derleyici iş parçacığı başlatacak şekilde değiştirildi. Ek iş parçacıkları başlatma ve kullanılmayan iş parçacıklarını kapatma dinamik olarak işlenir.

Çekirdek kitaplıklarda yapılan aşağıdaki değişikliklerin yeni veya değiştirilmiş kodun performansı üzerinde etkisi vardır.

• JEP 193: Değişken Tanıtıcıları [19] - Nesne alanları ve dizi öğeleri üzerinde çeşitli java.util.concurrent.atomic ve sun.misc.Unsafe işlemlerinin eşdeğerlerini çağırmak için standart bir araç, bellek sıralamanın ayrıntılı denetimi için standart bir çit işlemleri kümesi ve başvurulan nesnenin güçlü bir şekilde erişilebilir kalmasını sağlamak için standart bir ulaşılabilirlik çit işlemi tanımlar.

• JEP 269: Koleksiyonlar için Convenience Factory Yöntemleri [20] - Az sayıda öğe içeren koleksiyon ve harita örnekleri oluşturmayı kolaylaştırmak için kitaplık API'lerini tanımlar. Sıkıştırılmış, değiştirilemez koleksiyon örnekleri oluşturan koleksiyon arabirimlerindeki statik fabrika yöntemleri. Bu örnekler doğası gereği daha verimlidir. API'ler, küçük bir şekilde temsil edilen ve sarmalayıcı sınıfı olmayan koleksiyonlar oluşturur.

• JEP 285: Spin-Wait İpuçları [21] - Java'nın çalışma zamanı sistemine bir döndürme döngüsünde olduğunu ima etmesine olanak tanıyan API sağlar. Bazı donanım platformları, bir iş parçacığının meşgul bekleme durumunda olduğunu gösteren yazılım göstergesinden yararlanır.

• JEP 321: HTTP İstemcisi (Standart) [22]- HTTP/2 ve WebSocket uygulayan ve eski HttpURLConnection API'sinin yerini alan yeni bir HTTP istemci API'sini sağlar.

References

[1] Oracle Corporation, "Java Development Kit 9 Sürüm Notları", (Çevrimiçi). Kullanılabilir: https://www.oracle.com/technetwork/java/javase/9u-relnotes-3704429.html. (13 Kasım 2019'a erişildi).

[2] Oracle Corporation, "Java Development Kit 10 Sürüm Notları", (Çevrimiçi). Kullanılabilir: https://www.oracle.com/technetwork/java/javase/10u-relnotes-4108739.html. (13 Kasım 2019'a erişildi).

[3] Oracle Corporation, "Java Development Kit 11 Sürüm Notları", (Çevrimiçi). Kullanılabilir: https://www.oracle.com/technetwork/java/javase/11u-relnotes-5093844.html. (13 Kasım 2019'a erişildi).

[4] Oracle Corporation, "Project Jigsaw," 22 Eylül 2017. (Çevrimiçi). Kullanılabilir: http://openjdk.java.net/projects/jigsaw/. (13 Kasım 2019'a erişildi).

[5] Oracle Corporation, "JEP 328: Flight Recorder," 9 Eylül 2018. (Çevrimiçi) Kullanılabilir: http://openjdk.java.net/jeps/328. (13 Kasım 2019'a erişildi).

[6] Oracle Corporation, "Mission Control," 25 Nisan 2019. (Çevrimiçi) Kullanılabilir: https://wiki.openjdk.java.net/display/jmc/Main. (13 Kasım 2019'a erişildi).

[7] Oracle Corporation, "JEP 158: Unified JVM Logging," 14-Şubat-2019. (Çevrimiçi). Kullanılabilir: http://openjdk.java.net/jeps/158. (13 Kasım 2019'a erişildi).

[8] Oracle Corporation, "JEP 331: Low-Overhead Yığın Profili Oluşturma," 5 Eylül 2018. (Çevrimiçi) Mevcut: http://openjdk.java.net/jeps/331. (13 Kasım 2019'a erişildi).

[9] Oracle Corporation, "JEP 259: Stack-Walking API," 18 Temmuz 2017. (Çevrimiçi) Kullanılabilir: http://openjdk.java.net/jeps/259. (13 Kasım 2019'a erişildi).

[10] Oracle Corporation, "JEP 248: G1'i Varsayılan Çöp Toplayıcı Yap", 12 Eylül 2017. (Çevrimiçi). Kullanılabilir: http://openjdk.java.net/jeps/248. (13 Kasım 2019'a erişildi).

[11] Oracle Corporation, "JEP 318: Epsilon: A No-Op Çöp Toplayıcısı," 24 Eylül 2018. (Çevrimiçi) Kullanılabilir: http://openjdk.java.net/jeps/318. (13 Kasım 2019'a erişildi).

[12] Oracle Corporation, "JDK-8146115: Docker kapsayıcı algılama ve kaynak yapılandırma kullanımını geliştirme", 16 Eylül 2019. (Çevrimiçi). Kullanılabilir: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8146115. (13 Kasım 2019'a erişildi).

[13] Oracle Corporation, "JEP 238: Multi-Release JAR Files," 22 Haziran 2017. (Çevrimiçi). Kullanılabilir: http://openjdk.java.net/jeps/238. (13 Kasım 2019'a erişildi).

[14] Oracle Corporation, "JEP 197: Segmentli Kod Önbelleği", 28 Nisan 2017. (Çevrimiçi) Kullanılabilir: http://openjdk.java.net/jeps/197. (13 Kasım 2019'a erişildi).

[15] Oracle Corporation, "JEP 254: Compact Strings," 18 Mayıs 2019. (Çevrimiçi) Kullanılabilir: http://openjdk.java.net/jeps/254. (13 Kasım 2019'a erişildi).

[16] Oracle Corporation, "JEP 310: Uygulama Class-Data Paylaşımı," 17 Ağustos 2018. (Çevrimiçi). Kullanılabilir: https://openjdk.java.net/jeps/310. (13 Kasım 2019'a erişildi).

[17] Oracle Corporation, "JEP 312: Thread-Local Handshakes," 21 Ağustos 2019. (Çevrimiçi) Kullanılabilir: https://openjdk.java.net/jeps/312. (13 Kasım 2019'a erişildi).

[18] Oracle Corporation, "JDK-8198756: Derleyici iş parçacıklarının gecikmeli ayrılması", 29 Ekim 2018. (Çevrimiçi) Kullanılabilir: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8198756. (13 Kasım 2019'a erişildi).

[19] Oracle Corporation, "JEP 193: Değişken Tanıtıcılar", 17 Ağustos 2017. (Çevrimiçi) Kullanılabilir: https://openjdk.java.net/jeps/193. (13 Kasım 2019'a erişildi).

[20] Oracle Corporation, "JEP 269: Convenience Factory Methods for Collections", 26 Haziran 2017. (Çevrimiçi). Kullanılabilir: https://openjdk.java.net/jeps/269. (13 Kasım 2019'a erişildi).

[21] Oracle Corporation, "JEP 285: Spin-Wait İpuçları", 20 Ağustos 2017. (Çevrimiçi) Kullanılabilir: https://openjdk.java.net/jeps/285. (13 Kasım 2019'a erişildi).

[22] Oracle Corporation, "JEP 321: HTTP İstemcisi (Standart)," 27 Eylül 2018. (Çevrimiçi). Kullanılabilir: https://openjdk.java.net/jeps/321. (13 Kasım 2019'a erişildi).