2011-03-09 13 views
5

यह प्रश्न मेरे previous question के लिए दिए गए उत्तरों का नतीजा है।छवियां कैश हो रही हैं और मेरे हीप स्पेस को खा रही हैं

मुझे अपने ढेर को खाने के लिए जांच करने के लिए एक्लिप्स मैट का उपयोग करने के लिए कहा गया था। नीचे मेरी टिप्पणियों (टॉप उपभोक्ताओं को) कर रहे हैं:

class sun.awt.SunToolkit         333.7 MB 
com.tennisearth.service.impl.CacheManagerServiceImpl  136 MB 
org.apache.jasper.servlet.JspServlet      91.5 MB 

मैं पहले से ही CacheManageServiceImpl से जुड़ी समस्या सुलझा दिया है, लेकिन SunToolkit के साथ मदद की आवश्यकता है।

नीचे कोड है कि एक छवि वस्तु बनाता है (जो आंतरिक रूप से उपयोग करता SunToolkit.imgCache)

Image img = new ImageIcon(imagePath).getImage(); 
int imageWidth = img.getWidth(null); 
int imageHeight = img.getHeight(null); 

Plz ध्यान दें कि छवि वस्तु केवल जो बाद में आवश्यक है छवि के चौड़ाई/ऊंचाई प्राप्त करने के लिए बनाया जा रहा है है कुछ तर्क

क्या SunToolkit छवि कैशिंग अक्षम करने का कोई तरीका है? बेहतर अभी तक, क्या इस कैश को साफ़ करने का कोई तरीका है? या क्या कोई बेहतर तरीका है कि मैं इस जानकारी को पुनः प्राप्त कर सकता हूं?

आपके संदर्भ के लिए

Btw, मैं jboss चलाने के लिए (plz ध्यान दें ढेर आकार तर्क) नीचे आदेश का उपयोग कर रहा हूँ:

java -Dprogram.name=run.sh -server -Xms256m -Xmx1024m -XX:PermSize=64m -XX:MaxPermSize=256m -verbose:gc -Xloggc:/data1/logs/jboss/GC.log -XX:+HeapDumpOnOutOfMemoryError -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=false -Djava.net.preferIPv4Stack=true -Djava.library.path=/usr/local/java/jboss-4.2.2.GA/bin/native -Djava.endorsed.dirs=/usr/local/java/jboss-4.2.2.GA/lib/endorsed -classpath /usr/local/java/jboss-4.2.2.GA/bin/run.jar:/usr/local/java/jdk1.6.0_06/lib/tools.jar org.jboss.Main -c default -b <IP_ADDRESS> -Djboss.messaging.ServerPeerID=1 

सुमित

+1

छवियों और छवि कैशिंग से संबंधित जावा में * बहुत सारे मुद्दे हैं। एपीआई दोषों के आसपास कुख्यात * फ्लश() * वर्कअराउंड दिमाग में वसंत। छवियों को निरस्त करना हमेशा पर्याप्त नहीं होता है: कभी-कभी आपको * फ्लश() * को कॉल करने की आवश्यकता होती है और यह आसानी से समझ में नहीं आता है। यदि यह किसी सर्वर पर है, तो मुझे बाहरी रूप से ImageMagick की * पहचान * कमांड चलाकर उस चौड़ाई/ऊंचाई की जानकारी मिल जाएगी। बाहरी प्रक्रिया को चलाने के लिए यह थोड़ा दर्द है, लेकिन फिर सर्वर पर इसकी चौड़ाई/ऊंचाई प्राप्त करने के लिए एक छवि लोड करना काफी हेवीवेट है। – SyntaxT3rr0r

+0

एक और विकल्प ... हम बैच को हमारे सभी चित्रों को संसाधित कर रहे थे और विस्तृत रूप से चित्र के फ़ाइल नाम में विस्तृत/ऊंचाई जानकारी डाल रहे थे: * mypic.jpg * बन जाता है * mypic640x480.jpg *। फिर हमने फ़ाइल नाम से (डब्ल्यू, एच) निकाला ... – SyntaxT3rr0r

+0

यदि आप इस मुद्दे पर Google चाहते हैं, तो यहां एक दिलचस्प उद्धरण है: * हमने ओएस एक्स की तुलना में अन्य प्लेटफॉर्म पर फ्लश समस्या देखी है, इसलिए मुझे लगता है कि " जीसी ने छवि को पुनः प्राप्त करने से पहले फ्लश को मजबूर करने के लिए टूलकिट इमेज पर अंतिम रूप देने के द्वारा, सूर्य द्वारा उचित "फिक्स को जरूरी है। क्या किसी ने सूर्य को इसकी सूचना दी है? * – SyntaxT3rr0r

उत्तर

3

छवि कैश SoftCache नाम के एक वर्ग द्वारा कार्यान्वित किया जा रहा है, इसके प्रलेखन राज्यों निम्नलिखित:

Map इंटरफ़ेस का एक स्मृति के प्रति संवेदनशील कार्यान्वयन।

SoftCache ऑब्जेक्ट java.lang.ref.SoftReference मेमोरी-संवेदनशील हैश मानचित्र को लागू करने के लिए उपयोग करता है। यदि कचरा संग्राहक समय पर एक निश्चित बिंदु पर निर्धारित करता है कि SoftCache प्रविष्टि में कोई मान वस्तु अब दृढ़ता से पहुंच योग्य नहीं है, तो यह ऑब्जेक्ट द्वारा कब्जा कर लिया गया स्मृति जारी करने के लिए उस प्रविष्टि को हटा सकता है। वर्चुअल मशीन OutOfMemoryError फेंकने से पहले सभी SoftCache ऑब्जेक्ट्स पूरी तरह से होने की गारंटी दी जाती है।

तो मैं इस कैश द्वारा ली गई स्मृति के बारे में चिंता नहीं करता क्योंकि यह स्मृति की आवश्यकता होने पर स्वचालित रूप से साफ़ हो जाएगी।

संपादित करें:SyntaxT3rr0r द्वारा टिप्पणियां पढ़ने के बाद, मुझे लगता है कि यह अभी भी छवि पर flush कॉल करने के लिए सार्थक हो सकता है। यदि यह एक लक्ष्यीकरण विधि का हिस्सा है तो आप छवि को शून्य या रिफैक्टर पर भी सेट कर सकते हैं ताकि यह जल्द से जल्द गुंजाइश हो जाए।

एक और संभावना छवियों एपीआई को चौड़ाई और ऊंचाई को पुनर्प्राप्त करने का प्रयास करना होगा। यह ImageReader for the image type प्राप्त करके संभव होना चाहिए।

+1

आपकी स्पष्टीकरण के लिए बहुत बहुत धन्यवाद। खुशी है कि इस बारे में चिंता न करें :) – Sumit

+0

बस अपना संपादन देखा, मैं अभी भी छवि ऑब्जेक्ट बनाने की प्रक्रिया को तेज करने के लिए छवि कैशिंग का उपयोग करना चाहता हूं। मेरा मानना ​​है कि छवि को फ्लश करना इस कैश का उपयोग करने में सक्षम नहीं होगा। सही? – Sumit

+1

@ सुमित, मुझे नहीं पता कि उस कॉल द्वारा कौन से कैश फंस गए हैं। यदि आप बार-बार उसी छवि पथ के लिए चौड़ाई और ऊंचाई से पूछताछ करते हैं तो यह एक आसान कैश को लागू करने के लिए भी समझ सकता है, जैसे 'मानचित्र <स्ट्रिंग, चौड़ाई और हाइटबीन>'। जीसी द्वारा आईएमजीसीएच को मंजूरी मिलने के बाद यह छवि को फिर से बनाने की आवश्यकता से बच जाएगा। –

1

यह संभव अपने छवि वस्तु लंबे समय के लिए दायरे में रहता है है समय की अवधि? उदाहरण के लिए, यदि यह लंबे समय तक चलने वाले कोड के ब्लॉक के बाहरी दायरे में निहित है, तो यह उचित रूप से कचरा नहीं हो सकता है।

कभी-कभी (दुर्लभ मामलों में), यह स्पष्ट रूप से आपके छवि ऑब्जेक्ट संदर्भ को शून्य पर सेट करने के लिए फायदेमंद है। जैसा कि मैंने उपरोक्त उल्लेख किया है, यह सच होगा। अधिक जानकारी के लिए निम्नलिखित प्रश्न देखें: Does assigning objects to null in Java impact garbage collection?

संबंधित मुद्दे