बड़ी फ़ाइलों को संसाधित करने के लिए कस्टम इटरेटर

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

क्या कोई अनुकूलन या सर्वोत्तम प्रथाएं हैं जिन्हें मैं इस कस्टम पुनरावर्तनीय कार्यान्वयन पर लागू कर सकता हूं ताकि मेमोरी उपयोग को और कम किया जा सके या इसमें सुधार किया जा सके प्रदर्शन? संदर्भ के लिए कार्यान्वयन नीचे दिया गया है:

PostExceptionTasksHandler एक अनावश्यक प्रकार की तरह लगता है। यह मूल रूप से एक रननेबल है जिसे अपवाद होने पर निष्पादित किया जाता है। यह संभवतः अधिक उपयोगी होगा यदि आपने उस अपवाद को पारित कर दिया है जिसके कारण हैंडलर ने स्वयं हैंडलर को बुलाया है। यदि आप ऐसा करते हैं, तो हैंडलर प्रकार को उपभोक्ता से बदला जा सकता है और इसमें पहले से ही इसके नाम में पर्याप्त जानकारी शामिल है ताकि कॉलर को यह सुझाव दिया जा सके कि इसका उपयोग किस लिए किया जाता है।

यदि आपके पास MessageParserService तक पहुंच है। getMessageFromRowJson(String) विधि स्रोत कोड, मैं इसे शून्य वापस करने के बजाय एक अमान्य संदेश पर अपवाद फेंकने के लिए बदल दूंगा। इस तरह आप कॉल करने वाले को त्रुटि से निपटने के तरीके के बारे में निर्णय लेने के लिए अधिक जानकारी प्रदान करते हैं। यदि आप इसे ऐसे संदर्भ में उपयोग करना चाहते हैं जहां अपवाद वांछित नहीं हैं, तो शायद संदेश वर्ग को बदल दें ताकि इसमें वैधता के बारे में जानकारी हो ताकि आप रूपांतरण विधि से त्रुटि स्थिति वापस कर सकें।

MessageParserService लगता है जैसे कि यह वास्तविक सेवा से अधिक एक मैपर है। विधि हस्ताक्षर से पता चलता है कि यह JSON स्ट्रिंग को डेटा ऑब्जेक्ट में परिवर्तित करता है। ये निश्चित रूप से केवल नामकरण परंपराएं हैं और इस प्रकार अत्यधिक राय आधारित हैं, लेकिन मैं उन कक्षाओं को पसंद करता हूं जो MessageMapper.from(String source) जैसे नामकरण पैटर्न का पालन करने के लिए डेटा प्रकारों को परिवर्तित करते हैं। इसके लाभ हैं क्योंकि नाम क्लास के दायरे को संदेश ऑब्जेक्ट बनाने तक सीमित करता है और विधि का नाम स्पष्ट रूप से बताता है कि यह एक स्ट्रिंग से एक संदेश बनाता है। आपके मैपर में केवल "from" नाम की विधियाँ होने से आपको इसमें जिम्मेदारियाँ लोड करना शुरू करने से पहले दो बार सोचने में मदद मिलती है।

किसी त्रुटि को संभालने के लिए System.exit() को तब तक कॉल न करें जब तक आप ठीक से नहीं जानते कि आप ऐसा क्यों करना चाहते हैं . इस तथ्य के आधार पर कि आप कोड का वर्णन "अमान्य प्रविष्टियों को छोड़ना" के रूप में करते हैं, मुझे लगता है कि आप नहीं जानते हैं। क्योंकि System.exit अमान्य प्रविष्टियों को नहीं छोड़ता है। इसके बजाय यह वर्तनी संबंधी त्रुटि आने पर कंप्यूटर से पावर कॉर्ड को खींचने के बराबर है... इस बारे में स्टैक ओवरफ़्लो पर बहुत सारे संबंधित प्रश्न हैं। आप यहां से शुरू कर सकते हैं: https://stackoverflow.com/questions/3715967/when-should-we-call-system-exit-in-java

इसके लायक होने के लिए, शायद आप फ़ाइलों का उपयोग कर सकते हैं। इसके लिए एक विशेष पुनरावर्तक लिखने के बजाय पंक्तियाँ (पथ, वर्णसेट) विधि? कुछ इस तरह:

मैंने इस पर बहुत गहराई से ध्यान नहीं दिया है, लेकिन मैंने देखा है कि Iterator केवल hasNext में अगला मान उत्पन्न करता है, और Next मान लेता है कि यह पहले ही हो चुका है। इसका मतलब यह है कि यदि बीच में hasNext() के बिना कभी दो अगली() कॉल आती हैं, तो दूसरा हमेशा उस मूल्य के विपरीत शून्य वापस आ जाएगा जो उसे वापस आना चाहिए। यह मानने के बजाय कि नेक्स्ट की प्रत्येक कॉल के पहले एक हैसनेक्स्ट कॉल आएगी, इसे ऐसा बनाएं कि जरूरत पड़ने पर नेक्स्ट खुद ही पीढ़ी को आगे बढ़ा सके (ऐसा करने का एक तरीका हैसनेक्स्ट को कॉल करना हो सकता है। आगे बढ़ने वाले तर्क को एक सहायक विधि में तोड़ना जो दोनों अगला और hasNext व्यक्तिगत रूप से कॉल एक और है)।

इसके अतिरिक्त, अंतर्निहित संग्रह समाप्त होने पर Iterator::next() को NoSuchElementException फेंकना चाहिए। ऐसा प्रतीत होता है कि यह कार्यान्वयन ऐसा नहीं करता है।

अंत में, ऐसा लगता है कि हम संदेश पार्सिंग से दो अलग-अलग तरीकों से विफलता का संकेत देने की उम्मीद करते हैं - या तो IOException को फेंककर या शून्य लौटाकर। पूर्व को अच्छी तरह से संभाला जाता है। बाद वाले को System::exit के साथ पूरे प्रोग्राम को जबरन समाप्त करके नियंत्रित किया जाता है, जिससे कॉल करने वाले को ठीक होने या यहां तक ​​कि सफाई करने का कोई मौका नहीं मिलता है। इस मामले को उसी तरह से संभालना पसंद करें जैसे आप अन्य अपवाद पथ को संभालते हैं।

अस्वीकरण: मैं जावा प्रोग्रामर नहीं हूं (ला