थ्रेडलॉक के साथ मेमोरी लीक

महिलाओं और सज्जनों, मैं आपके साथ पैर में खुद को गोली मारने के लिए एक उल्लेखनीय तरीका साझा करना चाहता हूं, जिसे मैंने अपने घुटने पर एक अंग लिया, भले ही मैंने खुद को संगामिति-पुस्तकालय के क्षेत्र में विशेषज्ञ होने की कल्पना की हो। लेकिन थ्रेडलोक के रूप में इस तरह की एक साधारण बात मुझे नीचे, अप्रत्याशित रूप से और अप्रत्याशित रूप से सर्वर मेमोरी के अतिरिक्त गीगाबाइट के एक जोड़े को निगलने देती है।

बेशक, आपके सर्वर की मेमोरी को कचरे के भंडारण से बेहतर पाया जा सकता है। इसलिए मेरी गलती मत दोहराओ। अर्थात्: आपको थ्रेडलॉक में दिए गए लिंक को इस थ्रेडलोक में या वस्तुओं के कुछ ग्राफ में संग्रहीत करने का प्रयास नहीं करना चाहिए जो अंततः इस थ्रेडलोक को संदर्भित करता है।



शुरू करने के लिए, मैं एक कोड दे दूंगा:

class X { ThreadLocal<Anchor> local = new ThreadLocal<Anchor>(); class Anchor { byte[] data = new byte[1024 * 1024]; } public Anchor getOrCreate() { Anchor res = local.get(); if (res == null) { res = new Anchor(); local.set(res); } return res; } public static void doLeakOneMoreInstance() { new X().getOrCreate(); } public static void main(String[] args) throws Exception { while (true) { doLeakOneMoreInstance(); System.out.println(Runtime.getRuntime().freeMemory() / 1024 / 1024 + " MB of heap left"); } } } 

हर बार doLeakOneMoreInstance को X का एक नया उदाहरण बनाया जाता है, एक विधि को कहा जाता है जो ThreadLocal मान को सेट करता है, और फिर X का संदर्भ बिल्कुल खो जाता है। कंस्ट्रक्टर में निर्मित थ्रेडलोक उदाहरण का लिंक कभी भी X से आगे नहीं जाता है। ऐसा लगता है कि इसके बाद वस्तुओं के पूरे बनाए गए ग्राफ के लिए कोई बाहरी लिंक नहीं हैं और नहीं हो सकता है, और उन्हें जीसी द्वारा सुरक्षित रूप से हटाया जा सकता है।

लेकिन वहाँ यह था। यह कोड कुछ मामूली हीप आकार प्रतिबंध के साथ चलाने के लायक है, क्योंकि JVM गिर जाएगा, केवल संदेश "java.lang.OutOfMemoryError: Java हीप स्पेस" को छोड़कर, स्टैक ट्रेस का मुकुट (हालांकि, दिए गए वर्ग यह गीगाबाइट्स के एक जोड़े के रूप में बहुत ही भयानक है) सिर्फ कुछ मिलीसेकंड के लिए पर्याप्त)।

इससे पहले कि आप आगे पढ़ें, स्व-परीक्षण के रूप में प्रश्न का उत्तर देने का प्रयास करें: उपरोक्त खंड में केवल एक कीवर्ड जोड़कर OOM से कैसे छुटकारा पाया जाए?

बेशक, इस तरह के सिंथेटिक उदाहरण में, यह अनुमान लगाना आसान है कि थ्रेडलोक हर चीज के लिए दोषी है (क्योंकि इसके अलावा कुछ भी विशेष नहीं है), हालांकि, अगर यह एक बड़ी परियोजना में होता है जहां लाखों एक्स और जिंदा मृत और मृत हैं, तो समस्या की पहचान नहीं की जाएगी। सरल। हो सकता है कि किसी के लिए समाधान स्पष्ट हो, लेकिन व्यक्तिगत रूप से यह मेरे जीवन के एक घंटे से अधिक का समय था।

वास्तव में, समस्या क्या है?

(नीचे वर्णित सब कुछ ओरेकल के जेवीएम कार्यान्वयन के लिए सही है। हालांकि, अन्य भी प्रभावित हो सकते हैं।)

इस प्रश्न का उत्तर देने के लिए, आपको थ्रेडलोक के आंत्र में थोड़ा सा तलना होगा। तथ्य यह है कि थ्रेडलोक वैरिएबल का डेटा उन में संग्रहीत नहीं है, लेकिन सीधे थ्रेड ऑब्जेक्ट्स में। प्रत्येक थ्रेड में "कमजोर" कुंजियों (WeakHashMap का एक एनालॉग) के साथ एक शब्दकोश का अपना उदाहरण है, जहां थ्रेडलोकल इंस्टेंस कुंजी के रूप में कार्य करता है। जब आप थ्रेडलोक वैरिएबल को उसका मूल्य देने के लिए कहते हैं, तो यह वास्तव में वर्तमान थ्रेड को प्राप्त करता है, इसमें से एक शब्दकोश निकालता है, और शब्दकोश से मूल्य प्राप्त करता है, खुद को एक कुंजी के रूप में पसंदीदा के रूप में उपयोग करता है।

अगर थ्रेडलोकल का कोई लिंक नहीं है, तो कुंजी में शब्दकोश में प्रयुक्त लिंक को सुरक्षित रूप से अशक्त किया जाता है, और जब नए तत्वों को डाला जाता है, तो प्रविष्टियां साफ हो जाती हैं जो दूरस्थ जीसी ऑब्जेक्ट्स को संदर्भित करती हैं।

समस्या इस तंत्र में निहित है: चाबियों के कमजोर लिंक एक स्ट्रीम के अंदर एक शब्दकोश में संग्रहीत किए जाते हैं, लेकिन मूल्यों के लिए सीधे लिंक संग्रहीत होते हैं ! अगर, किसी तरह, थ्रेडलोकल वैल्यू (उदाहरण में, टाइप एंकर का ऑब्जेक्ट) के भीतर से, यह पता चलता है कि थ्रेडलोक युक्त यह प्राप्त करने योग्य है (उदाहरण में, चूंकि एंकर एक गैर-स्थैतिक वर्ग है, टाइप एक्स की एक ऑब्जेक्ट के लिए एक अंतर्निहित संदर्भ है, जो बदले में थ्रेडलोक को संदर्भित करता है। ), फिर जीसी थ्रेडलोक को ठीक से हटाने में सक्षम नहीं होगा, और यह सदियों के अंत तक, या जब तक मालिक धागा जीवित है, तब तक मृत वजन लटका रहता है।

खैर, आत्म-परीक्षण के लिए प्रश्न का उत्तर अब बहुत ही तुच्छ है: ताकि कोई स्मृति रिसाव न हो, यह एंकर क्लास में स्टेटिक कीवर्ड को जोड़ने के लिए पर्याप्त है, जिससे लिंक के दुष्चक्र खुलते हैं।

मुझे कहना होगा कि थ्रेडलोकल की वर्णित विशेषताओं में से एक और परेशानी बढ़ती है: जब तक कि थ्रेड जिसका मूल्य जीवित रहता है, कोई भी इसके साथ जुड़े थ्रेडलोक मान को हटाने की गारंटी नहीं देता है, भले ही थ्रेडलोक का लिंक खो गया हो: बिंदु है जब थ्रेडलोक इस थ्रेड के साथ जुड़े मानों तक पहुँचता है, और यदि थ्रेड नेटवर्क I / O के लिए प्रतीक्षा कर रहा है, सो रहा है या किसी अन्य लंबे ऑपरेशन को निष्पादित कर रहा है, तो पुराने मानों को केवल तभी साफ़ किया जाता है जब तक कि अनिश्चित काल तक प्रतीक्षा में देरी हो सकती है।

ThreadLocal, सहयोगियों के साथ सावधान रहें! उन में थ्रेडलोक के लिए लिंक न डालें, उनमें डेटा पेटाबाइट्स को संग्रहीत न करें। थ्रेडलोक के सही उपयोग की निगरानी करने की तुलना में कभी-कभी मानचित्र <थ्रेड, मान> का उपयोग करना अधिक आसान और विश्वसनीय होता है - इस मामले में आप कम से कम अपनी वस्तुओं के जीवन चक्र को नियंत्रित करते हैं।

PS हाँ, और मैंने जानबूझकर लेख को "मेमोरी लीक विथ थ्रेडलोकल" कहा है, न कि "मेमोरी लीक इन थ्रेडलोक": मेरी राय में, इस उपकरण का उपयोग करने में त्रुटि ठीक है, मानक पुस्तकालय स्वयं पूरी तरह से काम करता है।