2011-01-11 8 views
5

मेरे पास java.util.zip लाइब्रेरी से संबंधित कुछ सामान्य प्रश्न हैं। हम मूल रूप से क्या करते हैं एक आयात और कई छोटे घटकों का निर्यात है। इससे पहले इन घटकों का आयात किया गया है और एक भी बड़ी फ़ाइल, उदा .:java.util.zip - ZipInputStream vs.s. ZipFile

<component-type-a id="1"/> 
<component-type-a id="2"/> 
<component-type-a id="N"/> 

<component-type-b id="1"/> 
<component-type-b id="2"/> 
<component-type-b id="N"/> 

कृपया ध्यान दें कि आयात के दौरान घटकों के क्रम प्रासंगिक है का उपयोग कर निर्यात किया।

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

प्रश्न 1। ZipInputStream गारंटी दे सकता है कि ज़िप प्रविष्टियां (छोटी फ़ाइलें) उसी क्रम में पढ़ी जाएंगी जिसमें उन्हें हमारे निर्यात द्वारा डाला गया था जो ZipOutputStream का उपयोग करता है?


ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis)); 
ZipEntry entry; 
while((entry = zis.getNextEntry()) != null) 
{ 
     //read from zis until available 
} 

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

प्रश्न 2। अगर मैं ZipFile (जिसे मैं पसंद करता हूं) का उपयोग करता हूं तो getInputStream() को सैकड़ों बार कॉल करने का प्रदर्शन प्रभाव क्या है? क्या यह ZipInputStream समाधान से बहुत धीमा होगा? ज़िप केवल एक बार खोला जाता है और ZipFileRandomAccessFile द्वारा समर्थित है - क्या यह सही है? मुझे लगता है कि पढ़ने कुछ ऐसा है:


ZipFile zipfile = new ZipFile(argv[0]); 
Enumeration e = zipfile.entries();//TODO: assure the order of the entries 
while(e.hasMoreElements()) { 
     entry = (ZipEntry) e.nextElement(); 
     is = zipfile.getInputStream(entry)); 
} 

Q3। क्या इनपुट स्ट्रीम उसी ZipFile थ्रेड से पुनर्प्राप्त हैं (उदा। क्या मैं अलग-अलग धागे में अलग-अलग प्रविष्टियों को पढ़ सकता हूं)? कोई प्रदर्शन दंड?

आपके उत्तरों के लिए धन्यवाद!

उत्तर

3

प्रश्न 1: हाँ, आदेश वही होगा जिसमें प्रविष्टियां शामिल की गई थीं।

प्रश्न 2: ध्यान दें कि ज़िप संग्रह फ़ाइलों की संरचना के कारण, और संपीड़न, समाधानों में से कोई भी बिल्कुल स्ट्रीमिंग नहीं कर रहा है; वे सभी बफरिंग के कुछ स्तर करते हैं। और यदि आप जेडीके स्रोतों की जांच करते हैं, तो कार्यान्वयन अधिकतर कोड साझा करते हैं। सामग्री के भीतर कोई वास्तविक यादृच्छिक पहुंच नहीं है, हालांकि इंडेक्स प्रविष्टियों के अनुरूप भाग खोजने की अनुमति देता है। तो मुझे लगता है कि सार्थक प्रदर्शन मतभेद नहीं होना चाहिए; विशेष रूप से ओएस वैसे भी डिस्क ब्लॉक की कैशिंग करेगा। आप एक साधारण परीक्षण मामले के साथ इसे सत्यापित करने के लिए प्रदर्शन का परीक्षण करना चाह सकते हैं।

प्रश्न 3: मैं इस पर भरोसा नहीं करता; और सबसे अधिक संभावना है कि वे नहीं हैं। यदि आप वास्तव में सोचते हैं कि समवर्ती पहुंच मदद करेगा (ज्यादातर क्योंकि डिकंप्रेशन सीपीयू बाध्य है, इसलिए यह मदद कर सकता है), मैं पूरी फ़ाइल को स्मृति में पढ़ने की कोशिश करता हूं, बाइटएरेइन इनपुट स्ट्रीम के माध्यम से खुलासा करता हूं, और कई स्वतंत्र पाठकों का निर्माण करता हूं।

+0

हाय StaxMan! मैं बस जेडीके 6 में ज़िपफाइल $ ज़िपफाइलइनपुटस्ट्रीम के कार्यान्वयन की जांच कर रहा था। यह ZipFile.getInputStream द्वारा वापस किया गया है यह सिंक्रनाइज़ेशन है हालांकि मैं वास्तव में नहीं जानता कि यह कितना विश्वसनीय है। –

+0

हाँ, मैं यह सुनिश्चित नहीं कर सकता कि यह गैर-थ्रेड-सुरक्षित है। एक और खतरनाक हिस्सा अंतर्निहित देशी ज़्लिब लाइब्रेरी है, जो मुझे संदेह है कि थ्रेड-सुरक्षित नहीं है। – StaxMan

+6

मैं इस तथ्य की गवाही दे सकता हूं कि यह दर्दनाक अनुभव के माध्यम से थ्रेडसेफ नहीं है। – Joel

0

Q3 के बारे में, JENKINS-14362 में अनुभव पता चलता है कि zlib धागा सुरक्षित नहीं है भी जब असंबंधित धाराओं, अर्थात पर काम है कि यह कुछ अनुचित तरीके से साझा स्थिर राज्य है। साबित नहीं हुआ, बस एक चेतावनी।

1

मुझे लगा कि ZipInputStream के साथ फ़ाइलों को सूचीबद्ध करने से ZipFile के मुकाबले 8 गुना धीमी है।

long t = System.nanoTime(); 
    ZipFile zip = new ZipFile(jarFile); 
    Enumeration<? extends ZipEntry> entries = zip.entries(); 
    while (entries.hasMoreElements()) 
    { 
     ZipEntry entry = entries.nextElement(); 

     String filename = entry.getName(); 
     if (!filename.startsWith(JAR_TEXTURE_PATH)) 
      continue; 

     textureFiles.add(filename); 
    } 
    zip.close(); 
    System.out.println((System.nanoTime() - t)/1e9); 

और

long t = System.nanoTime(); 
    ZipInputStream zip = new ZipInputStream(new FileInputStream(jarFile)); 
    ZipEntry entry; 
    while ((entry = zip.getNextEntry()) != null) 
    { 
     String filename = entry.getName(); 
     if (!filename.startsWith(JAR_TEXTURE_PATH)) 
      continue; 

     textureFiles.add(filename); 
    } 
    zip.close(); 
    System.out.println((System.nanoTime() - t)/1e9); 

(उन्हें एक ही कक्षा में भागो मत। दो अलग अलग वर्गों और उन्हें अलग से चलाने)

+0

मेरा हंच ज़िपफाइल ज़िप इंडेक्स पढ़ रहा है जबकि ज़िपइनपूटस्ट्रीम पूरी ज़िप फ़ाइल को "लूपिंग" कर रहा है, एक फाइल के बाद एक फ़ाइल, एफडब्ल्यूआईडब्ल्यू। – rogerdpack

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