मुझे StringBuilder या StringBuffer का उपयोग कब करना चाहिए?

13

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

उदाहरण के लिए: (प्रत्येक डेटा बीन में मैं स्ट्रिंगर का उपयोग देख सकता हूं)

@Override
public String toString() {
    StringBuffer sb = new StringBuffer();// replace it from StringBuilder
    sb.append(" ABCD : ").append(abcd);
    sb.append(", EFGH : ").append(efgh);
    sb.append(", IJKL : ").append(ijkl);
}

हम प्रत्येक सत्र / अनुरोध के लिए एक अलग डेटा बीन्स बनाते हैं। एक सत्र का उपयोग एकल उपयोगकर्ता द्वारा किया जाता है कोई अन्य उपयोगकर्ता इसे एक्सेस नहीं कर सकता है।

क्या मुझे प्रवास करने से पहले अन्य बिंदुओं पर विचार करना चाहिए?

यदि कोई एकल थ्रेड है (वेटिंग थ्रेड्स (कोई नया थ्रेड ऑब्जेक्ट लॉक की तलाश में नहीं होगा), तो यह स्ट्रिंगबफ़र या स्ट्रिंगबर्ल के साथ समान रूप से कार्य करता है। मैं StringBuffer के मामले में जानता हूं, ऑब्जेक्ट लॉक को लेने में समय लगता है लेकिन मैं जानना चाहता हूं कि क्या ऑब्जेक्ट लॉक की पकड़ / रिलीज को छोड़कर उनके बीच कोई प्रदर्शन अंतर है।

— सतीश पांडे
स्रोत

9

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

— fredoverflow

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

— पेसटॉर्पिस्टिस्ट

उपयोगी हो सकता है: मैं प्रोग्रामेटिक रूप से कैसे साबित करूं कि स्ट्रिंगबर्ल थ्रेडसेफ़ नहीं है?

— एंड्रयू टोबिल्को

22

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

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

— मैथ्यू फ्लिन
स्रोत

मैं इसे इस बात से जोड़ूंगा कि आपको दोनों की विरासत की सुरक्षा को ध्यान में रखना होगा। StringBuilder धागा सुरक्षित नहीं है।

— मार्टिज़न वर्बर्ग

2

@MartijnVerburg सच, पूरी तरह से यह बताया गया था कि stackoverflow.com/questions/6775016/stringbuffer-is-obirect/… में कहा गया है कि स्ट्रिंग बिल्डर के एक ही उदाहरण का उपयोग करने के लिए कई थ्रेड की आवश्यकता वाले बहुत कम उपयोग के मामले हैं।

— मैथ्यू फ्लिन

4

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

— जोकिम सॉर

8

StringBuilder को एक बिंदु (जावा 1.5) में जोड़ा गया था जो एक बेहतर और तेज़ StringBuffer हो और संकलक इसे हुड के तहत +स्ट्रिंग्स पर ऑपरेटर को लागू करने के लिए उपयोग करता है ।

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

मैं निम्नलिखित कारणों से यद्यपि आपके द्वारा जाने वाली अनुकूलन प्रक्रिया से नहीं गुज़रूंगा।

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

— फ्रैंक शीयर
स्रोत

मैं आपकी बात से सहमत हूँ .. फिर भी आपकी बात नहीं समझ पा रहा हूँOutside tight loops the advantage is negligible...

— सतीश पाण्डेय

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