हम फिर से अनुकूलन, अनुकूलन और अनुकूलन करते हैं

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

तिथि

एक दर्जन से अधिक बार, मुझे यह देखने का अवसर मिला कि कैसे, उपयोगकर्ता से एक अनुरोध के प्रसंस्करण के दौरान, कई अलग-अलग स्थानों में एक नई तिथि वस्तु बनाई जाती है। सबसे अधिक, लक्ष्य एक ही है - वर्तमान समय प्राप्त करने के लिए। सबसे सरल मामले में, यह इस तरह दिखता है:

public boolean isValid(Date start, Date end) { Date now = new Date(); return start.before(now) && end.after(now); } 

यह प्रतीत होता है - एक पूरी तरह से स्पष्ट और सही समाधान। सिद्धांत रूप में, हाँ, दो अंकों के अपवाद के साथ:

• आज की तारीख में जावा का उपयोग करना शायद एक बुरा विचार है, इस तथ्य को देखते हुए कि इसमें लगभग सभी विधियां पहले से ही डिप्रेस्ड हैं।
• यदि आप पूरी तरह से लंबे आदिम के साथ मिल सकते हैं, तो एक नई तारीख वस्तु बनाने का कोई मतलब नहीं है:

  public boolean isValid(Date start, Date end) { long now = System.currentTimeMillis(); return start.getTime() < now && now < end.getTIme(); } 

SimpleDateFormat

बहुत बार वेब प्रोजेक्ट्स में टास्क को डेट में, या इसके विपरीत, स्ट्रिंग में डेट ट्रांसलेट करने का काम आता है। कार्य काफी विशिष्ट है और सबसे अधिक बार ऐसा दिखता है:

  return new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z").parse(dateString); 

यह एक सही और त्वरित समाधान है, लेकिन यदि सर्वर को प्रत्येक उपयोगकर्ता को सैकड़ों धाराओं में से प्रत्येक के लिए एक पंक्ति को पार्स करना है, तो यह सर्वर के प्रदर्शन को प्रभावित कर सकता है क्योंकि यह सिंपल हैवीवेटफार्मेट निर्माता के बजाय भारी वजन के कारण होता है, और फॉर्मैटर के अलावा, कई अन्य ऑब्जेक्ट बनाए जाते हैं लाइटवेट कैलेंडर (जिसका आकार> 400 बाइट्स) है।

SimpleDateFormat को एक स्थिर क्षेत्र बनाकर स्थिति को आसानी से हल किया जा सकता है, लेकिन यह थ्रेड सुरक्षित नहीं है। और एक प्रतिस्पर्धी माहौल में, आप आसानी से एक नंबरफ़ॉर्मैट अपवाद को पकड़ सकते हैं।

दूसरा विचार सिंक्रनाइज़ेशन का उपयोग करना है। लेकिन यह अभी भी एक संदिग्ध चीज है। धागे के बीच शानदार प्रतिस्पर्धा के मामले में, हम न केवल प्रदर्शन में सुधार कर सकते हैं, बल्कि बिगड़ भी सकते हैं।

लेकिन कम से कम 2 समाधान हैं:

• अच्छा पुराना थ्रेडलॉक - प्रत्येक थ्रेड के लिए SimpleDateFormat 1 बार बनाएं और प्रत्येक बाद के अनुरोध के लिए पुन: उपयोग करें। यह दृष्टिकोण प्रत्येक अनुरोध के लिए SimpleDateFormat वस्तुओं के निर्माण से बचने के द्वारा 2-4 बार पार्सिंग तिथियों को गति देने में मदद करेगा।
• SimpleDateFormat के लिए Joda और उसके धागे सुरक्षित समकक्ष DateTimeFormat है । हालाँकि, आयोडीन एक संपूर्ण के रूप में धीमी है, दिनांक निर्धारण में डिफ़ॉल्ट जावा डेट एपीआई की तुलना में, वे बराबर हैं। कुछ परीक्षण यहां देखे जा सकते हैं ।

बिना सोचे समझे

मेरी परियोजनाओं में, कार्य अक्सर उपयोगकर्ता को एक यादृच्छिक इकाई वापस करने के लिए उठता है। आमतौर पर, इस तरह का कोड इस तरह दिखता है:

  return items.get(new Random().nextInt(items.size())); 

महान, आसान, तेज। लेकिन, अगर विधि के लिए बहुत सारे कॉल हैं, तो इसका मतलब है कि नए रैंडम ऑब्जेक्ट्स का निरंतर निर्माण। क्या आसानी से बचा जा सकता है:

  private static final Random rand = new Random(); ... return items.get(rand.nextInt(items.size())); 

ऐसा लगता है कि यहाँ यह है - सही समाधान, लेकिन यहाँ यह इतना सरल नहीं है। इस तथ्य के बावजूद कि रैंडम थ्रेड सुरक्षित है, एक बहु-थ्रेडेड वातावरण में यह धीरे-धीरे काम कर सकता है। लेकिन सन ओरेकल ने पहले ही इस बात का ध्यान रखा है:

  return items.get(ThreadLocalRandom.current().nextInt(items.size())); 

जैसा कि प्रलेखन में कहा गया है - यह हमारे कार्य के लिए सबसे इष्टतम समाधान है। मल्टी-थ्रेडेड वातावरण में रैंडमोकेलरैंडम रैंडम की तुलना में बहुत अधिक कुशल है। दुर्भाग्य से, यह वर्ग केवल संस्करण 7 ( बग फिक्स के बाद, हाय थेशेड ) से शुरू होता है। संक्षेप में, यह समाधान SimpleDateFormat के साथ ही है, केवल अपने निजी वर्ग के साथ।

अशक्त नहीं

कई डेवलपर्स, शून्य मानों से बचते हुए, कुछ इस तरह लिखते हैं:

 public Item someMethod() { Item item = new Item(); //some logic if (something) { fillItem(item); } return item; } 

नतीजतन, भले ही कुछ सच न हो, फिर भी बड़ी संख्या में ऑब्जेक्ट बनाए जाएंगे (बशर्ते कि विधि को अक्सर कहा जाता है)।

regexp

यदि आप एक वेब एप्लिकेशन लिख रहे हैं, तो आप लगभग निश्चित रूप से नियमित अभिव्यक्ति का उपयोग कर रहे हैं। विशिष्ट कोड:

 public Item isValid(String ip) { Pattern pattern = Pattern.compile("xxx"); Matcher matcher = pattern.matcher(ip); return matcher.matches(); } 

पहले मामले में, जैसे ही एक नया आईपी पता आता है, हमें सत्यापन करना चाहिए। प्रत्येक कॉल के लिए फिर से - नई वस्तुओं के पैक। इस विशेष मामले में, कोड को थोड़ा अनुकूलित किया जा सकता है:

 private static final Pattern pattern = Pattern.compile("xxx"); public Item isValid(String ip) { Matcher matcher = pattern.matcher(ip); return matcher.matches(); } 

यह विधि के बाहर दियासलाई बनाने वाले के लिए भी आदर्श होगा, लेकिन दुर्भाग्य से यह थ्रेड सुरक्षित नहीं है और आपको इसे लगातार बनाना होगा। एकल-थ्रेडेड वातावरण के लिए, एक समाधान है:

 private static final Pattern pattern = Pattern.compile("xxx"); private final Matcher matcher = pattern.matcher(""); public Item isValid(String ip) { matcher.reset(ip); return matcher.matches(); } 

जो के लिए एकदम सही है ... सही, थ्रेडलोक।

ट्रंकट डेट

एक और काफी सामान्य कार्य दिनांक को घंटे, दिन, सप्ताह के हिसाब से रौंद रहा है। ऐसा करने के कई तरीके हैं, Apachevsky DateUtils से लेकर अपनी बाइक तक:

  public static Date truncateToHours(Date date) { Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC")); calendar.setTime(date); calendar.set(Calendar.HOUR_OF_DAY, 0); calendar.set(Calendar.MINUTE, 0); calendar.set(Calendar.SECOND, 0); calendar.set(Calendar.MILLISECOND, 0); return calendar.getTime(); } 

उदाहरण के लिए, हाल ही में, हडिप चरण के मानचित्र कोड का विश्लेषण करते हुए, मैं कोड की इन 2 पंक्तियों में आया, जिसमें 60% CPU खपत किया गया था:

 key.setDeliveredDateContent(truncateToHours(byPeriodKey.getContentTimestamp())); key.setDeliveredDateAd(truncateToHours(byPeriodKey.getAdTimestamp())); 

मेरे लिए यह एक बड़ा आश्चर्य था, लेकिन प्रोफाइलर झूठ नहीं बोल रहा है। सौभाग्य से, नक्शा विधि थ्रेड सुरक्षित होने के लिए निकली, और कैलेंडर ऑब्जेक्ट का निर्माण सफलतापूर्वक truncateToHours () विधि के बाहर हटा दिया गया था। जिसने मानचित्र विधि की गति 2 गुना बढ़ा दी।

HashCodeBuilder

मुझे नहीं पता कि क्यों, लेकिन कुछ डेवलपर्स हैशकोड () और बराबर () पद्धति को उत्पन्न करने के लिए अपाचेव्स्की हेल्पर कक्षाओं का उपयोग करते हैं। यहाँ एक उदाहरण है:

  @Override public boolean equals(Object obj) { EqualsBuilder equalsBuilder = new EqualsBuilder(); equalsBuilder.append(id, otherKey.getId()); ... } @Override public int hashCode() { HashCodeBuilder hashCodeBuilder = new HashCodeBuilder(); hashCodeBuilder.append(id); ... } 

यह, ज़ाहिर है, बुरा नहीं है यदि आप आवेदन के जीवन के दौरान कई बार इन विधियों का उपयोग करते हैं। लेकिन अगर उन्हें लगातार बुलाया जाता है, उदाहरण के लिए, हडूप नौकरी के सॉर्टेज चरण के दौरान प्रत्येक कुंजी के लिए, यह अच्छी तरह से निष्पादन की गति को प्रभावित कर सकता है।

निष्कर्ष

मैं क्यों हूँ - नहीं, मैं किसी भी तरह से चलाने के लिए आग्रह करता हूं कि कोड को चलाने और फावड़ा करने के लिए कुछ वस्तुओं को बनाने पर बचाने के लिए, यह विचार के लिए जानकारी है, संभावना है कि यह किसी के लिए बहुत उपयोगी होगा। पढ़ने के लिए धन्यवाद।