मेरे साथ भी ठीक यही समस्या आई. मुझे 3 थ्रेड्स के लिए 1 कनेक्शन को सक्रिय रखने की आवश्यकता थी और साथ ही प्रत्येक थ्रेड को बहुत सारे स्टेटमेंट (100k का ऑर्डर) निष्पादित करना था। मैं बहुत सावधान था और मैंने प्रत्येक कथन और प्रत्येक परिणाम को एक try....आखिरकार... एल्गोरिदम का उपयोग करके बंद कर दिया। इस तरह, भले ही कोड किसी तरह से विफल हो गया हो, बयान और परिणाम हमेशा बंद थे। 8 घंटे तक कोड चलाने के बाद मुझे यह जानकर आश्चर्य हुआ कि आवश्यक मेमोरी प्रारंभिक 35MB से 500MB तक चली गई। मैंने स्मृति का एक डंप उत्पन्न किया और मैंने ग्रहण से मैट विश्लेषक के साथ इसका विश्लेषण किया। यह पता चला कि एक com.mysql.jdbc.JDBC4Connection ऑब्जेक्ट कुछ ओपनस्टेटमेंट ऑब्जेक्ट्स को जीवित रखते हुए 445 एमबी मेमोरी ले रहा था, जो बदले में 135k हैशमैप प्रविष्टियों के आसपास जीवित रहा, शायद सभी परिणामों से। तो ऐसा लगता है कि यदि आप अपने सभी कथनों और परिणामों को बंद कर देते हैं, यदि आप कनेक्शन बंद नहीं करते हैं, तो यह उनके संदर्भ रखता है और गारबेज कलेक्टर संसाधनों को मुक्त नहीं कर सकता है।
मेरा समाधान :एक लंबी खोज के बाद मुझे यह कथन MySQL के लोगों से मिला:
"dontTrackOpenResources=true . को जोड़ने का एक त्वरित परीक्षण है "आपके JDBC URL पर। यदि मेमोरी लीक हो जाती है, तो आपके एप्लिकेशन में कुछ कोड पथ स्टेटमेंट और परिणाम सेट को बंद नहीं कर रहा है।"
यह लिंक है:http://bugs.mysql.com/bug.php? आईडी=5022 . तो मैंने कोशिश की और अनुमान लगाया क्या? 8 घंटे के बाद मुझे उसी डेटाबेस संचालन के लिए लगभग 40MB मेमोरी की आवश्यकता थी। हो सकता है कि एक कनेक्शन पूल उचित होगा, लेकिन अगर वह विकल्प नहीं है, तो यह अगली सबसे अच्छी बात है जो मैं आसपास आया था।
