क्यों स्ट्रिंगबिफर के पास स्ट्रिंगबिल्डर नहीं है जबकि स्ट्रिंगबिल्डर है?

Question

जेडीके 8, StringBuffer कक्षा में toStringCache है, जबकि StringBuilder नहीं है।

/** 
* A cache of the last value returned by toString. Cleared 
* whenever the StringBuffer is modified. 
*/ 
private transient char[] toStringCache; 

लेकिन क्यों?

• एक संभावित कारण यह है कि मैं सोच सकता हूं कि स्ट्रिंगबफर पहले ही सिंक्रनाइज़ है इसलिए कैश को कार्यान्वित किया जा सकता है।

• या शायद ऐतिहासिक रूप से स्ट्रिंगबफर को इस तरह कार्यान्वित किया गया था इसलिए पुराना कोड इस सुविधा पर भारी निर्भर करता है?

बचने के विश्लेषण और पक्षपातपूर्ण लॉकिंग के साथ आधुनिक जेवीएम को देखते हुए, क्या अंतर अब प्रासंगिक है?

Answer 1

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

इसकी आवश्यकता क्यों होगी, यह new String(...) कन्स्ट्रक्टर का उपयोग किया जाता है;

पैकेज निजी निर्माता जो गति के लिए मान सरणी साझा करता है: कि निर्माता String(array, boolean) टिप्पणी कहते हैं इस्तेमाल किया StringBuffer के मामले में।

Answer 2

यह ऐतिहासिक संदर्भ पर विचार करने में मदद कर सकता है। StringBuilder जावा 5 के साथ पेश किया गया था, क्योंकि यह पहचाना गया है कि StringBuffer इसके वास्तविक उपयोग मामलों के लिए उपयुक्त नहीं है।

नए पेश किए गए StringBuilder को पूरी तरह से स्थानीय संदर्भ में, निर्माण और उपयोग किए जाने के प्रमुख उपयोग के मामले के लिए डिज़ाइन किया गया है। इसलिए, यह कोई सिंक्रनाइज़ेशन प्रदान नहीं करता है और यह toString() विधि के दुर्लभ मामले को अनुकूलित करने के लिए परेशान नहीं करता है, जिसमें बदलाव के बीच कई बार कहा जाता है (वास्तविक जीवन में यह कब होता है?), खासकर वास्तव में , थ्रेड सिंक्रनाइज़ेशन के प्रदर्शन लाभ को बलि किए बिना कैशिंग सुविधा प्रदान करना, कहीं "कठिन" "असंभव" के बीच है।

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

तो यह अनुकूलन क्यों है, अगर वास्तविक जीवन में इसका कभी भी लाभ नहीं होता है? खैर, क्योंकि यह बहुत लंबे समय से है, जावा 1.0 के बाद भी सबसे अधिक संभावना है और कक्षा StringBuffer में कुछ भी बदलने के लायक नहीं है। अपनी उपस्थिति किसी भी वास्तविक लाभ नहीं हो सकता है, लेकिन न तो इसे हटाने है, जो नए परीक्षण और इतने पर की आवश्यकता होगी और बाहर बारी कुछ आवेदन के लिए space bar overheating feature होने के लिए कर सकता है ...

आपको लगता है कि वापस तो देख सकते हैं, जावा 1 में .x, बहुत से डिजाइन निर्णय किए गए थे जो आज अजीब लग सकते हैं।मौलिक कक्षाओं में synchronized का उपयोग करना उनमें से एक है, यह शायद ही कभी किसी अन्य को अनुकूलन में मदद करता है। उस समय, अपरिवर्तनीयता के प्रभाव भी अच्छी तरह से समझ में नहीं आये थे, यही कारण है कि हमारे पास String.valueOf(char[]) और String.copyValueOf(char[]), new String(char[]) का उपयोग करने का अवसर है ...