प्रदर्शन के तहत खान पंखों में इंतजार कर रहे हैं

इस लेख में मैं प्रदर्शन के तहत रखी गई खदानों के बारे में बात करूंगा, साथ ही उनका पता लगाना (अधिमानतः विस्फोट से पहले) और निपटान।

मेरा क्या है?

आइए किसी भी ज्ञान के मूल में निहित परिभाषा के साथ शुरू करें - परिभाषा के साथ। पूर्वजों ने कहा कि सही तरीके से नाम रखने का मतलब सही ढंग से समझना है। मुझे लगता है कि प्रदर्शन के तहत खानों की परिभाषा एक स्पष्ट गलती के विपरीत व्यक्त की जाती है, उदाहरण के लिए, यह:

String concat(String... strings) { String result = ""; for (String str : strings) { result += str; } return result; } 

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

लेकिन यह कोड बहुत कम ध्यान आकर्षित करेगा, और आइडिया ( संस्करण 2018.2 से पहले ) चुप हो जाएगा:

 Long total = 0L; List<Long> totals = query.getResultList(); for (Long element : totals) { total += element == null ? 0 : element; } 

यहां समस्या समान है: सरल प्रकार के लिए रैपर अपरिवर्तनीय हैं, जिसका अर्थ है कि ऑब्जेक्ट संख्या में 5 इकाइयों को जोड़ने का मतलब है कि एक नया आवरण बनाना और उसमें संख्या 6 लिखना।

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

वास्तव में, सब कुछ इतना सरल नहीं है। बेंचमार्क लें और संख्याओं को निर्दिष्ट तरीके से जोड़ने का प्रयास करें:

  (size) Mode Cnt Score Error Units wrapper 10 avgt 100 23,5 ± 0,1 ns/op wrapper 100 avgt 100 352,3 ± 2,1 ns/op wrapper 1000 avgt 100 4424,5 ± 25,2 ns/op wrapper 10 avgt 100 0 ± 0 B/op wrapper 100 avgt 100 1872 ± 0 B/op wrapper 1000 avgt 100 23472 ± 0 B/op 

 primitive 10 avgt 100 6,4 ± 0,0 ns/op primitive 100 avgt 100 39,8 ± 0,1 ns/op primitive 1000 avgt 100 252,5 ± 1,3 ns/op primitive 10 avgt 100 0 ± 0 B/op primitive 100 avgt 100 0 ± 0 B/op primitive 1000 avgt 100 0 ± 0 B/op 

यहां से हम प्रदर्शन के तहत खानों की परिभाषाओं में से एक को प्राप्त करते हैं - यह वह कोड है जो आंख को पकड़ता नहीं है, स्थैतिक विश्लेषणकर्ताओं द्वारा कम से कम (उस समय जब आप इसके पार आए थे) का पता नहीं लगाया जाता है, लेकिन यह कुछ उपयोगों में धीमा हो सकता है। हमारे मामले में, जबकि राशि १२ objects से अधिक नहीं है और वस्तुओं को कैश से लिया जाता है और Long की तुलना में केवल ४ गुना धीमी है। हालांकि, आकार 100 की एक सरणी के लिए, गति लगभग 10 गुना कम है।

बड़ी छोटी बातें

कभी-कभी एक छोटा सा बदलाव, जो निष्पादन के अर्थ को लगभग नहीं बदलता है, कुछ परिस्थितियों में एक मजबूत ब्रेक बन जाता है।

मान लीजिए कि हमारे पास एक कोड है:

 // org.springframework.data.convert.CustomConversions$ConversionTargetsCache Map<Object, TypeInformation<?>> cache = new ConcurrentHashMap<>(); private TypeInformation<?> getFromCacheOrCreate(Alias alias) { TypeInformation<?> info = cache.get(alias); if (info == null) { info = getAlias.apply(alias); cache.put(alias, info); } return info; } 

विधि लॉजिक कैसा दिखता है?

हमारे पास "आठ" है और हम कूल को कोड में सुधार कर सकते हैं: एक के साथ 6 लाइनों को बदलें, कोड को छोटा और समझने में आसान बना। वैसे, मल्टीथ्रेडिंग के पारखी संभवतः एक और सुधार को इंगित करेंगे कि ConcurrentHashMap::computeIfAbsent साथ लाता है, लेकिन इसके बारे में थोड़ी देर बाद;

आइए एक महान विचार को साकार करें:

 // org.springframework.data.convert.CustomConversions$ConversionTargetsCache Map<Object, TypeInformation<?>> cache = new ConcurrentHashMap<>(); private TypeInformation<?> getFromCacheOrCreate(Alias alias) { return cache.computeIfAbsent(alias, getAlias); } 

जबकि आवेदन एक धागे के साथ काम करता था, सब कुछ कम या ज्यादा अच्छा था। धाराएँ और भी बदतर होती गईं। यह ConcurrentHashMap::computeIfAbsent चला है कि ConcurrentHashMap::computeIfAbsent अवरुद्ध है, भले ही कुंजी को पहले ही शब्दकोश में जोड़ा गया हो । और यह स्प्रिंग डेट मानगो में काफी बग का कारण बन गया।

आप इसे एक साधारण माप ("आठ") के साथ सत्यापित कर सकते हैं। यहाँ उसका निष्कर्ष है:

 Benchmark Mode Cnt Score Error Units 1 thread computeIfAbsent avgt 20 19,405 ± 0,411 ns/op getAndPut avgt 20 4,578 ± 0,045 ns/op 2 threads computeIfAbsent avgt 20 66,492 ± 2,036 ns/op getAndPut avgt 20 4,454 ± 0,110 ns/op 4 threads computeIfAbsent avgt 20 155,975 ± 8,850 ns/op getAndPut avgt 20 5,616 ± 2,073 ns/op 6 threads computeIfAbsent avgt 20 203,188 ± 10,547 ns/op getAndPut avgt 20 7,024 ± 0,456 ns/op 8 threads computeIfAbsent avgt 20 302,036 ± 31,702 ns/op getAndPut avgt 20 7,990 ± 0,144 ns/op 

क्या इसे डेवलपर्स द्वारा स्पष्ट रूप से गलती माना जा सकता है? मेरी विनम्र राय में, नहीं, नहीं। प्रलेखन कहता है:

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

दूसरे शब्दों में, ConcurrentHashMap::computeIfAbsent उस सेल को बंद कर देता है जिसमें बाहर की दुनिया ( ConcurrentHashMap::get ) के विपरीत कुंजी होती है, जो आम तौर पर सच है, क्योंकि यह आपको विभिन्न थ्रेड्स के लिए एक विधि को कॉल करते समय दौड़ को चकमा देने की अनुमति देता है जब कुंजी को अभी तक जोड़ा नहीं गया है।

दूसरी ओर, ऑपरेशन के सबसे सामान्य मोड में, मूल्य की गणना और कुंजी के साथ इसकी बाइंडिंग केवल पहली कॉल पर होती है, और बाद की सभी कॉल केवल पहले की गणना की गई वैल्यू वापस करती हैं। इसलिए, यह तर्क को बदलने के लिए समझ में आता है ताकि ताला बदलते समय ही सेट हो। इसे यहां बनाया गया था ।

हाल के संस्करणों में (> 8), ConcurrentHashMap::computeIfAbsent हो गया है:

 JDK 11 Benchmark Mode Cnt Score Error Units 1 thread computeIfAbsent avgt 20 6,983 ± 0,066 ns/op getAndPut avgt 20 5,291 ± 1,220 ns/op 2 threads computeIfAbsent avgt 20 7,173 ± 0,249 ns/op getAndPut avgt 20 5,118 ± 0,395 ns/op 4 threads computeIfAbsent avgt 20 7,991 ± 0,447 ns/op getAndPut avgt 20 5,270 ± 0,366 ns/op 6 threads computeIfAbsent avgt 20 11,919 ± 0,865 ns/op getAndPut avgt 20 7,249 ± 0,199 ns/op 8 threads computeIfAbsent avgt 20 14,360 ± 0,892 ns/op getAndPut avgt 20 8,511 ± 0,229 ns/op 

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

 private TypeInformation<?> getFromCacheOrCreate(Alias alias) { TypeInformation<?> info = cache.get(alias); if (info == null) { info = getAlias.apply(alias); cache.put(alias, info); } return info; } 

इन हाथों ने कुछ भी नहीं बदला

ऐसा भी होता है कि कोड बिल्कुल नहीं बदलता है, लेकिन अचानक यह धीमा होना शुरू हो जाता है।

कल्पना कीजिए कि हम एक सरणी के तत्वों को एक संग्रह में स्थानांतरित करने के कार्य के साथ सामना कर रहे हैं। सबसे तार्किक तैयार किए गए Collection::addAll का उपयोग करना होगा, लेकिन यहां दुर्भाग्य है - यह संग्रह को स्वीकार करता है:

 public interface Collection<E> extends Iterable<E> { boolean addAll(Collection<? extends E> c); } 

सबसे आसान तरीका है Arrays::asList में Arrays::asList । यह कुछ इस तरह से बाहर हो जाएगा

 boolean addItems(Collection<T> collection) { T[] items = getArray(); return collection.addAll(Arrays.asList(items)); } 

प्रूफरीडिंग के दौरान, प्रदर्शन के प्रति जागरूक सहकर्मी शायद हमें बताएंगे कि इस कोड में दो समस्याएं हैं:

• किसी सूची में एक सरणी लपेटना (अतिरिक्त वस्तु)
• एक पुनरावृत्ति बनाने वाला (दूसरी अतिरिक्त वस्तु) और उससे होकर गुजरना

वास्तव में, Collection::addAll के संदर्भ कार्यान्वयन Collection::addAll हम इसे देखेंगे:

 public abstract class AbstractCollection<E> implements Collection<E> { public boolean addAll(Collection<? extends E> c) { boolean modified = false; for (E e : c) { if (add(e)) modified = true; } return modified; } } 

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

 boolean addItems(Collection<T> collection) { T[] items = getArray(); return Collections.addAll(collection, items); } 

कोड के अंदर, काफी अधिक उत्पादक प्रतीत होता है :

 public static <T> boolean addAll(Collection<? super T> c, T... elements) { boolean result = false; for (T element : elements) result |= c.add(element); return result; } 

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

अंत में, सहकर्मियों ने अल्टीमा अनुपात रेगम: प्रलेखन का हवाला दिया। और वहाँ, सफेद पर ग्रे (या काले पर हरा) कहते हैं:

 /** * ... * The behavior of this convenience method is identical to that of * c.addAll(Arrays.asList(elements)), but this method is likely * to run significantly faster under most implementations. <---- * @since 1.5 */ @SafeVarargs public static <T> boolean addAll(Collection<? super T> c, T... elements) { //... } 

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

बेंचमार्क , जिसे हम G8 पर HashSet लिए लॉन्च करेंगे, इसे HashSet करने में मदद करेगा:

 Benchmark (collection) (size) Mode Cnt Score Error Units addAll HashSet 10 avgt 100 155,2 ± 2,8 ns/op addAll HashSet 100 avgt 100 1884,4 ± 37,4 ns/op addAll HashSet 1000 avgt 100 17917,3 ± 298,8 ns/op collectionsAddAll HashSet 10 avgt 100 136,1 ± 0,8 ns/op collectionsAddAll HashSet 100 avgt 100 1538,3 ± 31,4 ns/op collectionsAddAll HashSet 1000 avgt 100 15168,6 ± 289,4 ns/op 

ऐसा लगता है कि अधिक अनुभवी कामरेड सही थे। लगभग।

बाद के संस्करणों में (उदाहरण के लिए, 11 में) उपयोगिता पद्धति की चमक कुछ फीकी पड़ जाएगी:

 Benchmark (collection) (size) Mode Cnt Score Error Units addAll HashSet 10 avgt 100 143,1 ± 0,6 ns/op addAll HashSet 100 avgt 100 1738,4 ± 7,3 ns/op addAll HashSet 1000 avgt 100 16853,9 ± 101,0 ns/op collectionsAddAll HashSet 10 avgt 100 132,1 ± 1,1 ns/op collectionsAddAll HashSet 100 avgt 100 1661,1 ± 7,1 ns/op collectionsAddAll HashSet 1000 avgt 100 15450,9 ± 93,9 ns/op 

यह देखा जा सकता है कि हम किसी भी "बहुत तेज" के बारे में बात नहीं कर रहे हैं। और अगर हम ArrayList -a के लिए प्रयोग दोहराते हैं, तो यह पता चलता है कि उपयोगिता विधि बहुत अधिक (आगे मजबूत) खोना शुरू कर देती है:

 Benchmark (collection) (size) Mode Cnt Score Error Units JDK 8 addAll ArrayList 10 avgt 100 38,5 ± 0,5 ns/op addAll ArrayList 100 avgt 100 188,4 ± 7,0 ns/op addAll ArrayList 1000 avgt 100 1278,8 ± 42,9 ns/op collectionsAddAll ArrayList 10 avgt 100 62,7 ± 0,7 ns/op collectionsAddAll ArrayList 100 avgt 100 495,1 ± 2,0 ns/op collectionsAddAll ArrayList 1000 avgt 100 4892,5 ± 48,0 ns/op JDK 11 addAll ArrayList 10 avgt 100 26,1 ± 0,0 ns/op addAll ArrayList 100 avgt 100 161,1 ± 0,4 ns/op addAll ArrayList 1000 avgt 100 1276,7 ± 3,7 ns/op collectionsAddAll ArrayList 10 avgt 100 41,6 ± 0,0 ns/op collectionsAddAll ArrayList 100 avgt 100 492,6 ± 1,5 ns/op collectionsAddAll ArrayList 1000 avgt 100 6792,7 ± 165,5 ns/op 

यहाँ कुछ भी अप्रत्याशित नहीं है, ArrayList एक सरणी के चारों ओर बनाया गया है, इसलिए डेवलपर्स ने दूर से Collection::addAll फिर से परिभाषित किया है:

 public boolean addAll(Collection<? extends E> c) { Object[] a = c.toArray(); modCount++; int numNew = a.length; if (numNew == 0) return false; Object[] elementData; final int s; if (numNew > (elementData = this.elementData).length - (s = size)) elementData = grow(s + numNew); System.arraycopy(a, 0, elementData, s, numNew); <---    size = s + numNew; return true; } 

अब वापस हमारे खानों में। मान लीजिए कि हमने फिर भी प्रूफरीडिंग पर प्रस्तावित समाधान को स्वीकार कर लिया और इस कोड को छोड़ दिया:

 boolean addItems(Collection<T> collection) { T[] items = getArray(); return Collections.addAll(collection, items); } 

कुछ समय के लिए, सब कुछ ठीक है, लेकिन नई कार्यक्षमता जोड़ने के बाद, विधि कभी-कभी गर्म हो जाती है और धीमा होने लगती है। हम स्रोत कोड खोलते हैं - कोड नहीं बदला। डेटा की मात्रा समान है। और प्रदर्शन बहुत कुछ डूब गया। यह मेरा एक और प्रकार है।

डिबगर को उजागर करें और सुंदर ढूंढें:

कृपया ध्यान दें: हमने एल्गोरिदम को नहीं बदला, संसाधित डेटा की मात्रा में बदलाव नहीं हुआ, लेकिन उनकी प्रकृति बदल गई और हमारे कोड में एक प्रदर्शन समस्या शुरू हुई:

  Java 8 Java 11  addAll 10 56,9 25,2 ns/op collectionsAddAll 10 352,2 142,9 ns/op addAll 100 159,9 84,3 ns/op collectionsAddAll 100 4607,1 3964,3 ns/op addAll 1000 1244,2 760,2 ns/op collectionsAddAll 1000 355796,9 364677,0 ns/op 

बड़े सरणियों पर, Collections::addAll और Collection::addAll बीच का अंतर एक मामूली 500 गुना है। तथ्य यह है कि COWList केवल मौजूदा सरणी का विस्तार नहीं करता है, लेकिन एक नया बनाता है जब प्रत्येक बार तत्व जोड़े जाते हैं:

 public boolean add(E e) { synchronized (lock) { Object[] es = getArray(); int len = es.length; es = Arrays.copyOf(es, len + 1); <----    es[len] = e; setArray(es); return true; } } 

किसे दोष देना है?

यहाँ मुख्य समस्या यह है कि Collections::addAll किसी इंटरफ़ेस को स्वीकार करती है, जबकि addAll पद्धति addAll कोई निकाय नहीं है। कोई निकाय - कोई व्यवसाय नहीं है, इसलिए, AbstractCollection::addAll में विद्यमान कार्यान्वयन के आधार पर लिखा जाता है, जो सभी संग्रह के लिए एक सामान्यीकृत एल्गोरिथम है। इसका मतलब है कि डेटा संरचनाओं के अधिक विशिष्ट कार्यान्वयन जो अमूर्तता के निचले स्तर पर हैं, इस व्यवहार को बदल सकते हैं।

  Collection::addAll –   AbstractCollection::addAll –   <---    ArrayList::addAll HashSet::addAll –   <---      COWList::addAll 

अमूर्तता के बारे में अधिक

चूंकि हम अमूर्तता के स्तरों के बारे में बात कर रहे हैं, मैं आपको जीवन से एक उदाहरण के बारे में बताऊंगा।

चलो डेटाबेस में संस्थाओं की संख्या की बचत के इन दो तरीकों की तुलना करते हैं:

 @Transactional void save(int n) { for (int i = 0; i < n; i++) { SimpleEntity e = new SimpleEntity(); repository.save(e); } } @Transactional void _save(int n) { for (int i = 0; i < n; i++) { SimpleEntity e = new SimpleEntity(); repository.saveAndFlush(e); } } 

पहली नज़र में, दोनों तरीकों का प्रदर्शन अलग-अलग नहीं होना चाहिए, क्योंकि

• दोनों ही मामलों में एक ही नंबर की इकाइयाँ डेटाबेस में संग्रहीत की जाएंगी
• यदि कुंजी अनुक्रम से ली गई है, तो कॉल की संख्या समान होगी
• स्थानांतरित किए गए डेटा की मात्रा समान है

SimpleJpaRepository::saveAndFlush की SimpleJpaRepository::saveAndFlush :

 @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else { return em.merge(entity); } } @Transactional public <S extends T> S saveAndFlush(S entity) { S result = save(entity); flush(); return result; } @Transactional public void flush() { em.flush(); } 

यहाँ डार्क स्पॉट flush() विधि है। क्यों गूंगा? यह मुझे लगता है कि JpaRepository इंटरफ़ेस में इसका खुलासा एक डेवलपर्स की गलती थी। मैं अपने विचार को सही ठहराने की कोशिश करूंगा। आमतौर पर, इस पद्धति का उपयोग डेवलपर द्वारा बिल्कुल भी नहीं किया जाता है, क्योंकि EntityManager::flush कॉल स्प्रिंग द्वारा नियंत्रित लेनदेन के पूरा होने से जुड़ा है:

 //     @Transactional public void method() { <--  Session::open /*.*/ } <--  Session::flush 

कृपया ध्यान दें: EntityManager Hibernate में सत्र (सत्र इंटरफ़ेस और SessionImpl वर्ग, क्रमशः) के रूप में कार्यान्वित JPA विनिर्देश का हिस्सा है। स्प्रिंग डेट एक फ्रेमवर्क है जो ओआरएम के शीर्ष पर चलता है, इस मामले में, हाइबरनेट के ऊपर। यह पता चला है कि JpaRepository::saveAndFlush हमें एपीआई के निचले स्तरों तक पहुंच प्रदान करती है, हालांकि फ्रेमवर्क का कार्य निम्न-स्तरीय विवरणों को छिपाना है (स्थिति जेडडीके में असुरक्षित कहानी के समान है)।
हमारे मामले में, जब JpaRepository::saveAndFlush का उपयोग करते हैं JpaRepository::saveAndFlush तो हम एप्लिकेशन की निचली परतों में पहुंच जाते हैं, जिससे कुछ होता है।

 spring: jpa: properties: hibernate: jdbc.batch_size: 500 

 @Transactional void save(int n) { for (int i = 0; i < n; i++) { SimpleEntity e = new SimpleEntity(); repository.save(e); } } 

 @Transactional void _save(int n) { for (int i = 0; i < n; i++) { SimpleEntity e = new SimpleEntity(); repository.saveAndFlush(e); } } 

इस प्रकार, आवेदन की निचली परतों के साथ हस्तक्षेप आसानी से एक खान बन सकता है, और न केवल एक उत्पादकता खान (देखें असुरक्षित और इसके अनियंत्रित उपयोग)।

यह कितना धीमा हो जाता है? सबसे अच्छा मामला ले लो (हमारे लिए) - डेटाबेस अनुप्रयोग के समान होस्ट पर है। मेरा माप निम्न चित्र दिखाता है:

  (entityCount) Mode Cnt Score Error Units bulkSave 10 ss 500 16,613 ± 1,714 ms/op bulkSave 100 ss 500 31,371 ± 1,453 ms/op bulkSave 1000 ss 500 35,687 ± 1,973 ms/op bulkSaveUsingFlush 10 ss 500 32,653 ± 2,166 ms/op bulkSaveUsingFlush 100 ss 500 61,983 ± 6,304 ms/op bulkSaveUsingFlush 1000 ss 500 184,814 ± 6,976 ms/op 

जाहिर है, यदि डेटाबेस एक दूरस्थ होस्ट पर स्थित है, तो डेटा वॉल्यूम बढ़ने के साथ डेटा ट्रांसफर की लागत प्रदर्शन को कम कर देगी।

इस प्रकार, अमूर्तता के गलत स्तर पर काम करने से आसानी से टाइम बम बनाया जा सकता है। वैसे, मेरे पिछले लेखों में से एक में मैंने StringBuilder -ए को बेहतर बनाने के लिए एक जिज्ञासु प्रयास के बारे में बात की थी: वहां मैं कोड के अधिक सार स्तर में आने की कोशिश करते समय असफल रहा था।

माइनफील्ड सीमाएँ

चलो एक सैपर खेलते हैं? मेरा खोजें:

 // org.springframework.cache.interceptor.CacheAspectSupport Object generateKey(CacheOperationContext ctx, Object result) { Object key = ctx.generateKey(result); Assert.notNull(key, "Null key ..." + context.metadata.operation); // ... return key; } 

  | \ / // org.springframework.cache.interceptor.CacheAspectSupport | \ / Object generateKey(CacheOperationContext ctx, Object result) { Object key = ctx.generateKey(result); | \ / Assert.notNull(key, "Null key ..." + context.metadata.operation); return key; } 

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

 // org.springframework.cache.interceptor.CacheAspectSupport Object generateKey(CacheOperationContext ctx, Object result) { Object key = ctx.generateKey(result); if (key == null) { throw new IAE("Null key ..." + context.metadata.operation); } // ... return key; } 

इस प्रकार, माइनफील्ड्स की सीमाएं हैं - यह डेटा की मात्रा, विधि तक पहुंच की आवृत्ति, आदि मात्रात्मक संकेतक हैं, जो पहुंचने और उससे अधिक होने पर एक मामूली खामी सांख्यिकीय रूप से महत्वपूर्ण हो जाती है।

दूसरी ओर, यह वह विशेषता है, जिसके प्रतिच्छेदन में कोड की जटिलता एक महत्वपूर्ण (औसत दर्जे का) सुधार नहीं देती है।

यह डेवलपर के लिए एक और निष्कर्ष है: ज्यादातर मामलों में, धोखा बुराई है, जिससे कोड की अर्थहीन जटिलता हो जाती है। 100 में से 99 मामलों में, हम कुछ भी नहीं जीतते हैं।

यह याद रखना चाहिए कि हमेशा होता है

एक सौवां मामला

यहाँ कोड है कि निट्ज़ेन वकार्ट अपने लेख में देता है वाष्पशील ने आश्चर्यचकित किया :

 @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Thread) public class LoopyBenchmarks { @Param({ "32", "1024", "32768" }) int size; byte[] bunn; @Setup public void prepare() { bunn = new byte[size]; } @Benchmark public void goodOldLoop(Blackhole fox) { for (int y = 0; y < bunn.length; y++) { // good old C style for (the win?) fox.consume(bunn[y]); } } @Benchmark public void sweetLoop(Blackhole fox) { for (byte bunny : bunn) { // syntactic sugar loop goodness fox.consume(bunny); } } } 

जब हम अनुभव सेट करते हैं, तो हम एक सरणी पर पुनरावृति करने के दो तरीकों के बीच एक अद्भुत अंतर की खोज करेंगे:

 Benchmark (size) Score Score error Units goodOldLoop 32 46.630 0.097 ns/op goodOldLoop 1024 1199.338 0.705 ns/op goodOldLoop 32768 37813.600 56.081 ns/op sweetLoop 32 19.304 0.010 ns/op sweetLoop 1024 475.141 1.227 ns/op sweetLoop 32768 14295.800 36.071 ns/op 

यहां, एक अनुभवहीन डेवलपर इस तरह के एक स्पष्ट और बेंचमार्क निष्कर्ष बना सकता है: एक गिनती चक्र की तुलना में नए सिंटैक्स कार्यों का उपयोग करके सरणी से गुजरना। यह गलत निष्कर्ष है, क्योंकि यह goodOldLoop विधि को goodOldLoop बदलने के लायक है:

 @Benchmark public void goodOldLoopReturns(Blackhole fox) { byte[] sunn = bunn; // make a local copy of the field for (int y = 0; y < sunn.length; y++) { fox.consume(sunn[y]); } } 

और इसका प्रदर्शन "तेज" sweetLoop विधि के sweetLoop है:

 Benchmark (size) Score Score error Units goodOldLoopReturns 32 19.306 0.045 ns/op goodOldLoopReturns 1024 476.493 1.190 ns/op goodOldLoopReturns 32768 14292.286 16.046 ns/op sweetLoop 32 19.304 0.010 ns/op sweetLoop 1024 475.141 1.227 ns/op sweetLoop 32768 14295.800 36.071 ns/op 

Blackhole::consume :

 //... public volatile byte b1, b2; public volatile BlackholeL2 nullBait = null; /** * Consume object. This call provides a side effect preventing JIT to eliminate dependent computations. * * @param b object to consume. */ public final void consume(byte b) { if (b == b1 & b == b2) { // SHOULD NEVER HAPPEN nullBait.b1 = b; // implicit null pointer exception } } 

, , . goodOldLoop this.bunn , for-each , (, Java Concurrency In Practice " "). .

: " ? , Blackhole::consume — JMH . , , ?"

:

 byte[] bunn; public void goodOldLoop(Blackhole fox) { for (int y = 0; y < bunn.length; y++) { fox.consume(bunn[y]); } } 

? ? , :

 E[] bunn; public void forEach(Consumer<E> fox) { for (int y = 0; y < bunn.length; y++) { fox.consume(bunn[y]); } } 

Iterable::forEach ! , , , ( JDK 13):

 //ArrayList public void forEach(Consumer<? super E> action) { Objects.requireNonNull(action); final int expectedModCount = modCount; final Object[] es = elementData; final int size = this.size; for (int i = 0; modCount == expectedModCount && i < size; i++) action.accept(elementAt(es, i)); if (modCount != expectedModCount) throw new ConcurrentModificationException(); } //Arrays$ArrayList public void forEach(Consumer<? super E> action) { Objects.requireNonNull(action); for (E e : a) { action.accept(e); } } //CopyOnWriteArrayList public void forEach(Consumer<? super E> action) { Objects.requireNonNull(action); for (Object x : getArray()) { @SuppressWarnings("unchecked") E e = (E) x; action.accept(e); } } //ArrayDeque public void forEach(Consumer<? super E> action) { Objects.requireNonNull(action); final Object[] es = elements; for (int i = head, end = tail, to = (i <= end) ? end : es.length; ; i = 0, to = end) { for (; i < to; i++) action.accept(elementAt(es, i)); if (to == end) { if (end != tail) throw new ConcurrentModificationException(); break; } } } 

, . , Collections.nCopies()::forEach :

 @Override public void forEach(final Consumer<? super E> action) { Objects.requireNonNull(action); for (int i = 0; i < this.n; i++) { action.accept(this.element); } } 

, . . this.n this.element :

 private static class CopiesList<E> extends AbstractList<E> implements RandomAccess, Serializable { final int n; final E element; CopiesList(int n, E e) { assert n >= 0; this.n = n; element = e; } 

, , @Stable .

: 99 100 , , 1 100, . , .

" volatile".

, :

 //java.lang.Integer @HotSpotIntrinsicCandidate public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); } 

- , ( java.lang.Integer , java.lang.Long , java.lang.Short , java.lang.Byte , java.lang.Character ). , ,

 Integer intgr = Integer.valueOf(42); 

.

:

 Integer intgr = new Integer(42); 

, , Integer::valueOf .

: . , , "" ( ). , , Integer::valueOf . " " .

. , . , . , , .