Yay alma talebinin çeşitli yöntemleri ve iplik güvenliği analizi
Bir Web sistemi geliştirmek için Spring MVC'yi kullanırken, istemcinin IP adresini, istenen URL'yi, başlıktaki öznitelikleri (çerezler, yetkilendirme bilgileri gibi) ve gövde içindeki verileri alma gibi istekleri işlerken genellikle istek nesnesini kullanmak gerekir. Spring MVC'de, Controller, Service ve isteği işleyen diğer nesnelerin hepsi tekil olduğundan, istek nesnesini alırken dikkat edilmesi gereken en önemli şey, istek nesnesinin iş parçacığı açısından güvenli olup olmadığıdır: çok sayıda eşzamanlı istek olduğunda, olabilir mi? Farklı isteklerde / iş parçacıklarında farklı istek nesnelerinin kullanıldığından emin olun.
Burada not edilmesi gereken başka bir sorun daha var: daha önce bahsedilen "istek işlenirken" istek nesnesinin kullanımı nerede? İstek nesnelerini elde etme yöntemlerinin biraz farklı olduğu düşünüldüğünde, bunlar kabaca iki kategoriye ayrılabilir:
1. Spring Beans'teki istek nesnelerini kullanın: Controller, Service ve Repository gibi MVC Beans ve Component gibi yaygın Spring Beans dahil. Açıklama kolaylığı açısından, aşağıdaki metinde tüm Baharda Fasulye olarak anılacaktır.
2. Beans olmayanlarda istek nesnelerini kullanın: sıradan Java nesnelerinin yöntemlerinde veya sınıfın statik yöntemlerinde olduğu gibi.
Buna ek olarak, bu makaledeki tartışma, isteği temsil eden istek nesnesine odaklanır, ancak kullanılan yöntemler aynı zamanda yanıt nesneleri, InputStream / Reader, OutputStream / Writer vb. İçin de geçerlidir; bunların arasında, InputStream / Reader istekteki verileri okuyabilir ve OutputStream / Writer yanıt verebilir veri girişi.
Son olarak, istek nesnesini elde etme yöntemi de Spring ve MVC sürümleriyle ilgilidir; bu makale tartışma için Spring4'e dayanmaktadır ve yapılan deneylerin tümü 4.1.1 sürümünü kullanmaktadır.
İki, iplik güvenliği nasıl test edilir
Talep nesnesinin iş parçacığı güvenliği, sonraki tartışmayı kolaylaştırmak için özel dikkat gerektirdiğinden, aşağıda istek nesnesinin iş parçacığı açısından güvenli olup olmadığının nasıl test edileceği açıklanmaktadır.
Testin temel fikri, istemciden gelen çok sayıda eşzamanlı isteği simüle etmektir ve ardından sunucu, bu isteklerin aynı istek nesnesini kullanıp kullanmadığına karar verir.
İstek nesnelerinin aynı olup olmadığını belirlemenin en sezgisel yolu, istek nesnesinin adresini yazdırmaktır, eğer aynıysa, aynı nesne kullanılır. Bununla birlikte, web sunucularının hemen hemen tüm uygulamalarında, iş parçacığı havuzları kullanılır, bu da birbiri ardına gelen ve aynı iş parçacığı tarafından işlenebilen iki istekle sonuçlanır: önceki istek işlendikten sonra, iş parçacığı havuzu iş parçacığını geri alır ve İş parçacığı sonraki isteklere yeniden atandı. Aynı iş parçacığında, kullanılan istek nesnesi muhtemelen aynıdır (aynı adres, farklı öznitelikler). Bu nedenle, iş parçacığı güvenli yöntemler için bile, farklı istekler aynı istek nesnesi adresini kullanabilir.
Bu sorunu önlemek için, bir yöntem, iş parçacığını istek işleme sırasında birkaç saniye uyutmaktır, böylece her iş parçacığı aynı iş parçacığının farklı isteklere atanmasını önlemek için yeterince uzun süre çalışabilir; diğer yöntem kullanmaktır. İsteğin diğer öznitelikleri (parametreler, başlık, gövde vb. Gibi), isteğin iş parçacığı açısından güvenli olup olmadığının temeli olarak kullanılır, çünkü farklı istekler aynı iş parçacığını kullansa bile (istek nesnesi adresi aynıdır), iki kez oluşturmak için farklı öznitelikler kullanıldığı sürece istek nesnesi varsa, istek nesnesinin kullanımı iş parçacığı açısından güvenlidir. Bu makale, test için ikinci yöntemi kullanır.
İstemci test kodu aşağıdaki gibidir (istekleri ayrı olarak göndermek için 1000 iş parçacığı oluşturun):
Sunucudaki Denetleyici kodu aşağıdaki gibidir (İstek nesnesini alma kodu geçici olarak ihmal edilmiştir):
İstek nesnesi iş parçacığı açısından güvenli ise, sunucudaki yazdırma sonucu aşağıdaki gibidir:
Bir iş parçacığı güvenliği sorunu varsa, sunucudaki yazdırma sonucu aşağıdaki gibi olabilir:
Özel bir talimat yoksa, test kodu bu makalenin arkasındaki kodda yer almayacaktır.
3. Yöntem 1: Denetleyiciye parametreler ekleyin
1. Kod örneği
Bu yöntem, doğrudan Denetleyici kodu üzerinde uygulanması en basit yöntemdir:
Bu yöntemin ilkesi, Controller yöntemi isteği işlemeye başladığında, Spring'in istek nesnesini yöntem parametrelerine atamasıdır. İstek nesnesine ek olarak, bu yöntemle elde edilebilecek daha birçok parametre vardır. Ayrıntılar için bkz: https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc-ann- yöntemler
Denetleyicide istek nesnesini aldıktan sonra, istek nesnesini başka yöntemlerde (hizmet yöntemleri, araç yöntemleri vb.) Kullanmak istiyorsanız, bu yöntemleri çağırırken istek nesnesini parametre olarak iletmeniz gerekir.
2. İplik güvenliği
Test sonucu: iplik güvenliği
Analiz: Şu anda, istek nesnesi, şüphesiz iş parçacığı açısından güvenli olan yerel bir değişkene eşdeğer bir yöntem parametresidir. Konu Güvenli Harita bu makaleyi görüntülemek için buraya tıklayabilir.
3. Avantajlar ve dezavantajlar
Bu yöntemin temel dezavantajı, istek nesnesinin yazılamayacak kadar fazla olması ve bu temelde iki noktada yansıtılıyor:
(1) Birden çok denetleyici yönteminde istek nesnesi gerekiyorsa, istek parametresinin her yönteme eklenmesi gerekir.
(2) İstek nesnesi yalnızca denetleyiciden elde edilebilir.İstek nesnesi daha derin bir işlev çağrısı düzeyinde kullanılıyorsa, tüm çağrı zincirindeki tüm yöntemlerin istek parametreleri eklemesi gerekir.
Aslında, tüm istek işleme sürecinde, istek nesnesi çalışır; yani, zamanlayıcılar gibi özel durumlar dışında, istek nesnesi iş parçacığı içindeki bir global değişkene eşdeğerdir. Ve bu yöntem, bu küresel değişkeni ileri geri aktarmaya eşdeğerdir.
