Sun.misc.Unsafe क्यों मौजूद है, और इसे वास्तविक दुनिया में कैसे इस्तेमाल किया जा सकता है? [बन्द है]


267

मैं दूसरे दिन sun.misc.Unsafe पैकेज में आया था और यह क्या कर सकता है पर चकित था।

बेशक, कक्षा अनिर्धारित है, लेकिन मैं सोच रहा था कि क्या कभी इसका उपयोग करने का एक अच्छा कारण था। ऐसे परिदृश्य उत्पन्न हो सकते हैं जहाँ आपको इसका उपयोग करने की आवश्यकता होगी? वास्तविक दुनिया के परिदृश्य में इसका उपयोग कैसे किया जा सकता है?

इसके अलावा, यदि आपको इसकी आवश्यकता है, तो क्या यह इंगित नहीं करता है कि आपके डिजाइन में कुछ गलत है?

जावा इस वर्ग को भी क्यों शामिल करता है?


7
JDK देव वर्तमान में जावा 9 में एक सार्वजनिक एपीआई में संभावित परिवर्तन के लिए इस एपीआई की समीक्षा कर रहे हैं। यदि आप इसका उपयोग करते हैं, तो सर्वेक्षण को भरने के लिए 5 मिनट का समय लगता है: Surveyymonkey.com/s/sun-misc-Unsafe
एंडी लिंच

2
: इस पोस्ट पर मेटा चर्चा हो रही है meta.stackoverflow.com/questions/299139/...
जॉन क्लेमेंट्स

जवाबों:


159

उदाहरण

  1. वीएम "आंतरिकता।" यानी कैस (तुलना-और-स्वैप) लॉक-फ्री हैश टेबल्स में उपयोग किया जाता है जैसे: sun.misc.Unsafe.compareAndSwapInt यह वास्तविक JNI कॉल को मूल कोड में कर सकता है जिसमें CAS के लिए विशेष निर्देश हैं।

    यहां CAS के बारे में अधिक पढ़ें http://en.wikipedia.org/wiki/Compare-and-swap

  2. Sun.misc.Unsafe की कार्यक्षमता मेजबान VM का उपयोग असंगठित वस्तुओं को आवंटित करने के लिए किया जा सकता है और फिर किसी अन्य विधि कॉल के रूप में निर्माता के आह्वान की व्याख्या कर सकता है।

  3. कोई व्यक्ति मूल पते से डेटा ट्रैक कर सकता है। यह java.lang.Unsafe वर्ग का उपयोग करके किसी ऑब्जेक्ट के मेमोरी एड्रेस को पुनः प्राप्त करना संभव है, और असुरक्षित प्राप्त / पुट विधियों के माध्यम से सीधे अपने खेतों पर काम कर सकता है!

  4. जेवीएम के लिए संकलन समय अनुकूलन। "जादू" का उपयोग करते हुए HIgh प्रदर्शन, निम्न-स्तरीय संचालन की आवश्यकता होती है। जैसे: http://en.wikipedia.org/wiki/Jikes_RVM

  5. मेमोरी आवंटित करना, sun.misc.Unsafe.allocateMemory उदा: - DirectByteBuffer कंस्ट्रक्टर आंतरिक रूप से इसे तब कॉल करता है जब ByteBuffer.allocateDirect इनवॉइस होता है

  6. कॉल स्टैक को ट्रेस करना और sun.misc.Unsafe द्वारा इंस्टेंट किए गए मानों के साथ फिर से खेलना, इंस्ट्रूमेंटेशन के लिए उपयोगी है

  7. sun.misc.Unsafe.arrayBaseOffset और arrayIndexScale का उपयोग सरणी को विकसित करने के लिए किया जा सकता है, स्कैन के लिए वास्तविक समय लागत को सीमित करने, अपडेट करने या बड़ी वस्तुओं में संचालन को स्थानांतरित करने के लिए कुशलतापूर्वक बड़ी वस्तुओं को बड़ी वस्तुओं में तोड़ने के लिए एक तकनीक।

  8. http://robaustin.wikidot.com/how-to-write-to-direct-memory-locations-in-java

यहाँ संदर्भों पर और अधिक - http://bytescrolls.blogspot.com/2011/04/interesting-uses-of-sunmiscunotafe.html


1
यदि आपको असुरक्षित का उपयोग करके किसी फ़ील्ड का पता मिलता है, तो इसे हमेशा GC द्वारा बदला जा सकता है, तो क्या यह ऑपरेशन बहुत बेकार नहीं है?
20

उन लोगों के लिए पता प्राप्त करें जिन्हें आपने आवंटित किया है
zudokod

मेरे द्वारा आवंटित किए जाने का वास्तव में क्या मतलब है । ऐसा उन स्थानों पर उपयोग किया जा रहा है जहाँ ऑब्जेक्ट 'नए' ऑपरेटर के उपयोग से बनाए गए थे, इस प्रकार यह मेरा प्रश्न है।
pdeva

1
uns..ococateMemory और वैल्यू डाल दिया
zudokod

1
बिंदु 2 के बारे में, मैं जानना चाहूंगा कि आप किसी अन्य विधि के रूप में निर्माता को कैसे आमंत्रित कर सकते हैं? क्योंकि मुझे ऐसा करने का कोई तरीका नहीं मिला, जब तक कि बाईटकोड में नहीं।
मिगुएल गैंबो

31

बस कुछ कोड खोज इंजन में खोज चलाने से मुझे निम्नलिखित उदाहरण मिलते हैं:

{@ अनलिंक असुरक्षित} ऑब्जेक्ट तक पहुंच प्राप्त करने के लिए सरल वर्ग। {@link Unsafe} * सरणियों पर कुशल CAS संचालन की अनुमति देने के लिए आवश्यक है। ध्यान दें कि संस्करण {@link java.util.concurrent.atomic}, जैसे कि {@link java.util.concurrent.atomic.AtomicLongArray} में, अतिरिक्त मेमोरी ऑर्डर गारंटी की आवश्यकता होती है जो आमतौर पर इन एल्गोरिदम में आवश्यक नहीं होती हैं और महंगी भी होती हैं। अधिकांश प्रोसेसरों पर।

/ ** sun.misc के लिए बेस क्लास। स्थिर क्षेत्रों के लिए Unsafe-based FieldAccessors। अवलोकन यह है कि प्रतिबिंब कोड के दृष्टिकोण से केवल नौ प्रकार के क्षेत्र हैं: आठ आदिम प्रकार और वस्तु। उत्पन्न बायोटेक्स के बजाय क्लास असुरक्षित का उपयोग करने से डायनामिकली-जेनरेट किए गए फील्डअसेक्टर्स के लिए मेमोरी और लोडिंग समय की बचत होती है। * /

  • SpikeSource

/ * FinalFields जो तार के पार भेजे जाते हैं .. कैसे प्राप्त करें और प्राप्त पक्ष पर ऑब्जेक्ट को फिर से बनाना है? हम कंस्ट्रक्टर को आमंत्रित नहीं करना चाहते हैं क्योंकि यह अंतिम क्षेत्रों के लिए मूल्य स्थापित करेगा। हमें अंतिम फ़ील्ड को फिर से बनाना होगा जैसे यह प्रेषक की तरफ था। Sun.misc.Unsafe हमारे लिए ऐसा करता है। * /

कई अन्य उदाहरण हैं, बस उपरोक्त लिंक का पालन करें ...


25

दिलचस्प है, मैं इस वर्ग के बारे में कभी नहीं सुना था (जो कि शायद एक अच्छी बात है, वास्तव में)।

एक बात जो मन में उछलती है वह बफर को शून्य करने के लिए Unsafe # setMemory का उपयोग कर रही है जिसमें एक बिंदु (पासवर्ड, कुंजी, ...) पर संवेदनशील जानकारी थी। तुम भी "अपरिवर्तनीय" वस्तुओं के क्षेत्रों के लिए ऐसा कर सकते हैं (फिर मुझे लगता है कि सादे पुराने प्रतिबिंब यहाँ भी चाल कर सकते हैं)। मैं कोई सुरक्षा विशेषज्ञ नहीं हूँ, लेकिन नमक के एक दाने के साथ इसे लेते हैं।


4
I'd never even heard of this class... मैंने आपको इसके बारे में कई बार बताया है! sigh + :(
टिम बेंडर

7
इसका कोई मतलब नहीं होगा, क्योंकि जावा एक प्रतिलिपि जनरेटिंग कचरा कलेक्टर का उपयोग करता है और आपकी संवेदनशील जानकारी संभवतः पहले से ही 'मुक्त' मेमोरी में कहीं और स्थित होगी जो ओवरराइट होने की प्रतीक्षा कर रही है।
डैनियल कैसिडी

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

1
@ डैनियल, दिलचस्प, मैंने ऐसा नहीं माना था। अब आप देख सकते हैं कि मैं सुरक्षा विशेषज्ञ क्यों नहीं हूं। :)
माइक डेनियल

22

संदर्भ ट्रेसिंग के लिए ग्रहण का उपयोग करके जावा 1.6.12 पुस्तकालय के एक बहुत ही संक्षिप्त विश्लेषण के आधार पर, ऐसा लगता है जैसे कि हर उपयोगी कार्यक्षमता Unsafeउपयोगी तरीकों से उजागर होती है।

कैस संचालन को परमाणु * कक्षाओं के माध्यम से उजागर किया जाता है। DirectByteBuffer सिंक निर्देशों (पार्क, अनपार्क) के माध्यम से मेमोरी जोड़तोड़ कार्यों को उजागर किया जाता है, जो AbstractQueuedSynchronizer के माध्यम से उजागर होता है जो बदले में लॉक कार्यान्वयन द्वारा उपयोग किया जाता है।


AtomicXXXUpdaters बहुत धीमी हैं और जब आपको वास्तव में उनकी आवश्यकता होती है: CAS - तो आप उन्हें वास्तव में उपयोग करने का जोखिम नहीं उठा सकते हैं। यदि आप धातु करने जा रहे हैं तो आप अमूर्त स्तरों और कई जाँचों का उपयोग नहीं करेंगे। कैस को फेल करना लूप एस्प में एक खराब है। जब हार्डवेयर शाखा को गलत ठहराने का फैसला करता है (उच्च विवाद के कारण), लेकिन कुछ और तुलना / शाखाएं होने से दर्द होता है। पार्क / Unpark के माध्यम से संपर्क में हैं LockSupportनहीं AQS (कि बाद एक ताला impl अधिक है पार्क / unpark से।)
bestsss

21

Unsafe.throwException - उन्हें घोषित किए बिना चेक किए गए अपवाद को फेंकने की अनुमति देता है।

यह कुछ मामलों में उपयोगी है जहां आप प्रतिबिंब या एओपी से निपटते हैं।

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

import org.junit.Test;
/** need to allow forbidden references! */ import sun.misc.Unsafe;

/**
 * Demonstrate how to throw an undeclared checked exception.
 * This is a hack, because it uses the forbidden Class {@link sun.misc.Unsafe}.
 */
public class ExceptionTest {

    /**
     * A checked exception.
     */
    public static class MyException extends Exception {
        private static final long serialVersionUID = 5960664994726581924L;
    }

    /**
     * Throw the Exception.
     */
    @SuppressWarnings("restriction")
    public static void throwUndeclared() {
        getUnsafe().throwException(new MyException());
    }

    /**
     * Return an instance of {@link sun.misc.Unsafe}.
     * @return THE instance
     */
    @SuppressWarnings("restriction")
    private static Unsafe getUnsafe() {
        try {

            Field singleoneInstanceField = Unsafe.class.getDeclaredField("theUnsafe");
            singleoneInstanceField.setAccessible(true);
            return (Unsafe) singleoneInstanceField.get(null);

        } catch (IllegalArgumentException e) {
            throw createExceptionForObtainingUnsafe(e);
        } catch (SecurityException e) {
            throw createExceptionForObtainingUnsafe(e);
        } catch (NoSuchFieldException e) {
            throw createExceptionForObtainingUnsafe(e);
        } catch (IllegalAccessException e) {
            throw createExceptionForObtainingUnsafe(e);
        }
    }

    private static RuntimeException createExceptionForObtainingUnsafe(final Throwable cause) {
        return new RuntimeException("error while obtaining sun.misc.Unsafe", cause);
    }


    /**
     * scenario: test that an CheckedException {@link MyException} can be thrown
     * from an method that not declare it.
     */
    @Test(expected = MyException.class)
    public void testUnsingUnsaveToThrowCheckedException() {
        throwUndeclared();
    }
}

14
आप एक ही w / Thread.stop(Throwable)असुरक्षित की कोई आवश्यकता नहीं कर सकते हैं, एक ही धागे में आप कुछ भी फेंक सकते हैं (कोई संकलन नहीं है)
bestsss

आप इसे विशुद्ध रूप से बायटेकोड के माध्यम से कर सकते हैं (या लोम्बोक का उपयोग इसे आपके लिए करने के लिए करें)
Antimony

1
@bestsss उस विधि को बाहर निकाल दिया गया है और UnsupportedOperationExceptionजावा 8 के रूप में वर्तमान थ्रेड में फेंकता है । हालांकि, नो-तर्क संस्करण जो ThreadDeathअभी भी काम करता है।
गपरानी

@damryfbfnetsi, मैंने कुछ समय के लिए कोर jdk चर्चाओं का पालन नहीं किया है और जावा 8 में जाने की कोई योजना नहीं है। फिर भी, यह काफी हैरान करने वाला विचार है क्योंकि इसे बायटेकोड पीढ़ी द्वारा वैसे भी लागू किया जाना है, जब तक कि अब सत्यापनकर्ता वास्तव में जाँच नहीं करते हैं विधि फेंकों की घोषणा करती है ... लेकिन यह कि पिछड़े असंगत हो सकते हैं क्योंकि फेंक अपवाद के बारे में मेटाडेटा को छोड़ने के लिए स्वतंत्र था।
bestsss

10

कक्षा असुरक्षित

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

इसका एक उपयोग java.util.concurrent.atomicकक्षाओं में है:


6

कुशल मेमोरी कॉपी के लिए (कम से कम ब्लॉक के लिए System.arraycopy () की तुलना में तेजी से कॉपी करने के लिए); जैसा कि Java LZF और Snappy codecs द्वारा उपयोग किया जाता है । वे 'गेटलॉन्ग' और 'पुटलॉन्ग' का उपयोग करते हैं, जो बाइट-बाय-बाइट करने से ज्यादा तेज़ होते हैं; 16/32/64 बाइट ब्लॉक जैसी चीजों की नकल करते समय विशेष रूप से कुशल।


1
Doh, arraycopy SS86 लूप्स का x86-64 पर उपयोग करता है जो इससे बेहतर हैं getLong/putLong(और आपको पते की गणना भी
करनी है

क्या आपने वास्तव में इसे मापा है? छोटे ब्लॉकों के लिए मैं x86-64 पर लगातार बेहतर प्रदर्शन देखता हूं जब getLong/ का संयोजन का उपयोग करता putLongहूं: आदर्श रूप से मैं System.arraycopy()सादगी और सभी के लिए पसंद करूंगा ; लेकिन वास्तविक परीक्षण से पता चलता है कि मैंने जिन मामलों का परीक्षण किया है।
स्टेक्समैन

हाँ असुरक्षित का उपयोग करके मैं किसी भी सार्थक प्रदर्शन को अव्यवस्थित रूप से नहीं कर सकता। कई बाइट्स के लिए बड़ी सरणियों पर लंबी प्रतियां मिलती हैं / पुटॉन्ग वास्तव में काम कर सकता है जब कंपाइलर को लंबाई की जांच करनी होती है। कुछ फंसा हुआ। पिछले जोड़ स्मृति बाड़ System.arrayCopy (हालांकि अक्षम / सक्षम किया जा सकता है), ताकि असली अपराधी हो सकता है।
bestsss

ठीक। यह संभव है कि नए जेडीके ने इसे बदल दिया है; मूल रूप से जब मैंने तेजी से ऑपरेशन का अवलोकन किया (JDK 1.6 के साथ) तो मुझे भी आश्चर्य हुआ। या शायद मैं उपयोग में कुछ विशिष्ट अंतर को भूल रहा हूं। ये मुश्किल (और संभवतः अस्थिर) अनुकूलन होते हैं, तब भी जब वे काम करते हैं, और प्रभावों को मापना आवश्यक है।
स्टेक्समैन

5

मैं हाल ही में जेवीएम को फिर से लागू करने पर काम कर रहा था और पाया कि वर्गों की एक आश्चर्यजनक संख्या के संदर्भ में लागू किया जाता है Unsafe। यह क्लास ज्यादातर जावा लाइब्रेरी के कार्यान्वयनकर्ताओं के लिए डिज़ाइन की गई है और इसमें ऐसी विशेषताएं शामिल हैं जो मौलिक रूप से असुरक्षित हैं लेकिन फास्ट प्राइमेटिव के निर्माण के लिए आवश्यक हैं। उदाहरण के लिए, कच्चे क्षेत्र के ऑफ़सेट प्राप्त करने और लिखने के लिए तरीके हैं, हार्डवेयर-स्तरीय सिंक्रनाइज़ेशन का उपयोग करना, मेमोरी को आवंटित करना और मुक्त करना आदि, यह सामान्य जावा प्रोग्रामर द्वारा उपयोग किए जाने का इरादा नहीं है; यह अनिर्दिष्ट है, कार्यान्वयन-विशिष्ट, और स्वाभाविक रूप से असुरक्षित (इसलिए नाम!)। इसके अलावा, मुझे लगता है कि SecurityManagerयह लगभग सभी मामलों में इस तक पहुंच को समाप्त कर देगा।

संक्षेप में, यह मुख्य रूप से मूल रूप से कुछ वर्गों में प्रत्येक विधि की घोषणा किए बिना पुस्तकालय कार्यान्वयनकर्ताओं को अंतर्निहित मशीन तक पहुंचने की अनुमति देने के लिए मौजूद AtomicIntegerहै। आपको नियमित जावा प्रोग्रामिंग में इसके बारे में उपयोग करने या चिंता करने की आवश्यकता नहीं है, क्योंकि पूरे बिंदु को बाकी पुस्तकालयों को पर्याप्त तेजी से बनाना है ताकि आपको उस तरह की पहुंच की आवश्यकता न हो।


वास्तव में, SecurityManager केवल तब तक इसे
रोक देता

@ निखर उठती है- क्या आप इस बारे में विस्तार से बता सकते हैं?
templatetypedef

जब एक उदाहरण getUnsafe से मिल रहा है, बल्कि उसके Unsafe.class.getDeclaredField("theUnsafe")साथ सख्त आवश्यकताएं हैं, .setAccessible(true)तो .get(null)वह इसे भी पूरा कर लेगा
amara

@ निखर उठती है- मुझे आश्चर्य है कि काम करता है - सुरक्षा प्रबंधक को ध्वजांकित करना चाहिए।
templatetypedef

5

इसे उपयोग करने के लिए और बड़ी मात्रा में मेमोरी को कुशलतापूर्वक आवंटित करने के लिए उपयोग करें, जैसे कि आपके अपने स्वयं के voxel इंजन में! (यानी Minecraft शैली खेल।)

मेरे अनुभव में, JVM अक्सर सीमा-जाँच को समाप्त करने में असमर्थ है, जिसकी आपको वास्तव में आवश्यकता है। उदाहरण के लिए, यदि आप एक बड़े सरणी पर पुनरावृत्ति कर रहे हैं, लेकिन वास्तविक मेमोरी एक्सेस लूप में एक नॉन-वर्चुअल * मेथड कॉल के नीचे टिकी हुई है, तो JVM अभी भी एक बार पहले की बजाय प्रत्येक ऐरे एक्सेस के साथ सीमा जाँच कर सकता है। सूचित करते रहना। इस प्रकार, संभावित बड़े प्रदर्शन लाभ के लिए, आप JVM सीमा-जाँच को एक विधि के माध्यम से लूप के अंदर समाप्त कर सकते हैं, जो कि sun.misc.Unsafe को सीधे मेमोरी तक पहुँचने के लिए नियत करता है, जिससे किसी भी सीमा-जाँच को सही स्थानों पर करना सुनिश्चित होता है। (आप कुछ स्तर पर सही जाँच कर रहे हैं?)
* गैर-आभासी द्वारा, मेरा मतलब है कि जेवीएम को गतिशील रूप से हल नहीं करना चाहिए जो भी आपकी विशेष विधि है, क्योंकि आपने सही ढंग से गारंटी दी है कि क्लास / मेथड / इंस्टेंस में स्टेटिक / फ़ाइनल / व्हाट्स-यू-यू के कुछ संयोजन हैं।

मेरे घरेलू-विकसित स्वर इंजन के लिए, इसने चंक पीढ़ी और क्रमांकन के दौरान एक नाटकीय प्रदर्शन हासिल किया (iow स्थानों पर जहां मैं एक बार में पूरे सरणी को पढ़ / लिख रहा था)। परिणाम भिन्न हो सकते हैं, लेकिन यदि सीमा-उन्मूलन की कमी आपकी समस्या है, तो यह इसे ठीक कर देगा।

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


4

जीसी हस्तक्षेप के बिना उपयोग के तुरंत बाद मेमोरी को भारी मात्रा में आवंटित करने और तुरंत निपटने के लिए ऑफ-हीप संग्रह उपयोगी हो सकता है। मैंने ऑफ-हीप सरणियों / सूचियों के आधार पर काम करने के लिए एक पुस्तकालय लिखा था sun.misc.Unsafe


4

हमने Arrays, HashMaps, TreeMaps जैसे विशाल संग्रह को Unsafe का उपयोग करके लागू किया है।
और विखंडन को कम करने / कम करने के लिए, हमने असुरक्षित से अधिक dlmalloc की अवधारणाओं का उपयोग करके मेमोरी एलोकेटर को लागू किया ।
इससे हमें समरूपता में प्रदर्शन हासिल करने में मदद मिली।


3

Unsafe.park()और Unsafe.unpark()कस्टम संगामिति नियंत्रण संरचनाओं और सहकारी निर्धारण तंत्र के निर्माण के लिए।


24
सार्वजनिक रूप से उपलब्ध हैjava.util.concurrent.locks.LockSupport
बेस्टसीएस

1

स्वयं इसका उपयोग नहीं किया है, लेकिन मुझे लगता है कि अगर आपके पास एक ऐसा चर है जो केवल कभी-कभार एक से अधिक धागे से पढ़ा जाता है (इसलिए आप वास्तव में इसे अस्थिर नहीं करना चाहते हैं) तो आप putObjectVolatileइसे मुख्य धागे में लिखते समय उपयोग कर सकते हैं readObjectVolatileजब दुर्लभ अन्य धागे से पढ़ता है।


1
लेकिन नीचे दिए गए सूत्र पर चर्चा के अनुसार, अनियंत्रित अस्थिरता लगभग उतनी ही तेजी से गैर-वाष्पशील होती है, जितनी भी stackoverflow.com/questions/5573782/…
pdeva

आप वाष्पशील लेखों और वाष्पशील लेखों के साथ अस्थिर शब्दार्थों को प्रतिस्थापित नहीं कर सकते हैं ... यह आपदा का एक नुस्खा है क्योंकि यह एक सेटिंग्स में काम कर सकता है लेकिन किसी अन्य में नहीं। यदि आप एक एकल लेखक धागे के साथ वाष्पशील शब्दार्थ देख रहे हैं, तो आप पाठकों पर AtomicReference.lazySet का उपयोग कर सकते हैं और () विषय पर चर्चा के लिए इस पोस्ट को देखें )। वाष्पशील रीड अपेक्षाकृत सस्ते होते हैं, लेकिन मुफ्त नहीं, यहां देखें ।
निट्सन वकार्ट

"... आप इसे लिखते समय putObjectVolatile का उपयोग कर सकते हैं ..." मैं सादे लेखन का सुझाव नहीं दे रहा था।
मैट क्रिंकलाव-वोग्ट

1

यदि आपको वर्तमान में इसका उपयोग करने वाले वर्गों में से एक द्वारा प्रदान की गई कार्यक्षमता को बदलने की आवश्यकता है, तो आपको इसकी आवश्यकता है।

यह कस्टम / तेज / अधिक कॉम्पैक्ट क्रमांकन / डीसेरलाइज़ेशन हो सकता है, बाइटबफ़र का तेज़ / बड़ा बफ़र / रिसाइज़ वर्ज़न या परमाणु चर जोड़ सकता है जैसे वर्तमान में समर्थित नहीं है।

मैंने किसी समय इन सभी के लिए इसका इस्तेमाल किया है।



0

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

जैसा कि woliveirajr ने कहा कि "यादृच्छिक ()" Unsafe को बीज के रूप में उपयोग करता है, जैसा कि कई अन्य संचालन Unsafe में शामिल आवंटन () फ़ंक्शन का उपयोग करेंगे।

एक प्रोग्रामर के रूप में आप शायद इस पुस्तकालय की कभी जरूरत न होने पाए, लेकिन निम्न-स्तरीय तत्वों पर सख्त नियंत्रण रखने से काम नहीं आता है (इसीलिए अभी भी विधानसभा और कुछ हद तक सी कोड प्रमुख उत्पादों में घूम रहा है)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.