চূড়ান্ত নয় এমন ক্ষেত্রের সিঙ্ক্রোনাইজেশন

Question 1

আমি যখন কোনও চূড়ান্ত শ্রেণীর ক্ষেত্রের সাথে সিঙ্ক্রোনাইজ করি তখন প্রতিবার একটি সতর্কতা প্রদর্শিত হচ্ছে। কোডটি এখানে:

public class X  
{  
   private Object o;  

   public void setO(Object o)  
   {  
     this.o = o;  
   }  

   public void x()  
   {  
     synchronized (o) // synchronization on a non-final field  
     {  
     }  
   }  
 }

সুতরাং আমি নিম্নলিখিত পদ্ধতিতে কোডিংটি পরিবর্তন করেছি:

 public class X  
 {  

   private final Object o;       
   public X()
   {  
     o = new Object();  
   }  

   public void x()  
   {  
     synchronized (o)
     {  
     }  
   }  
 }

আমি নিশ্চিত নই যে উপরোক্ত কোডটি একটি চূড়ান্ত নয় এমন শ্রেণীর ক্ষেত্রের সাথে সিঙ্ক্রোনাইজ করার উপযুক্ত উপায়। আমি কীভাবে একটি চূড়ান্ত নয় এমন ক্ষেত্রটিকে সিঙ্ক্রোনাইজ করতে পারি?

Question 2

প্রথমত, আমি আপনাকে উচ্চতর স্তরের বিমূর্ততার সাথে সমঝোতার বিষয়গুলি মোকাবিলা করার জন্য সত্যিই কঠোর প্রচেষ্টা করতে উত্সাহিত করি, যেমন java.util.concurrent যেমন এক্সিকিউটর সার্ভিস, কল্যাবলস, ফিউচার ইত্যাদির ক্লাস ব্যবহার করে এটি সমাধান করা

এটি বলা হচ্ছে যে, প্রতি সেফ কোনও চূড়ান্ত ক্ষেত্রের সাথে সিঙ্ক্রোনাইজ করার ক্ষেত্রে কোনও ভুল নেই। আপনার কেবল মনে রাখতে হবে যে যদি অবজেক্টের রেফারেন্স পরিবর্তন হয় তবে কোডের একই বিভাগটি সমান্তরালে চালানো যেতে পারে । অর্থাৎ, একটি থ্রেড সিঙ্ক্রোনাইজ ব্লক এবং কেউ কল কোড রান setO(...), অন্য থ্রেড চালাতে পারেন একই সিঙ্ক্রোনাইজ ব্লক একই উদাহরণস্বরূপ একই সময়ে।

আপনার যে একচেটিয়া অ্যাক্সেসের প্রয়োজন তা (বা এটি আরও ভাল, এটি রক্ষার জন্য উত্সর্গীকৃত কোনও বস্তুর) জন্য সিঙ্ক্রোনাইজ করুন।

Question 3

এটি সত্যিই ভাল ধারণা নয় - কারণ আপনার সিঙ্ক্রোনাইজ করা ব্লকগুলি আর একটি সুসংগত উপায়ে সত্যিই সিঙ্ক্রোনাইজ হয় না।

সিঙ্ক্রোনাইজড ব্লকগুলি ধরে নেওয়া মানে বোঝানো হচ্ছে যে একবারে কেবল একটি থ্রেড কিছু শেয়ারড ডেটা অ্যাক্সেস করে, বিবেচনা করুন:

থ্রেড 1 সিঙ্ক্রোনাইজড ব্লকে প্রবেশ করে। হ্যাঁ - এটি ভাগ করা ডেটা একচেটিয়া অ্যাক্সেস আছে ...
থ্রেড 2 কল সেটও ()
থ্রেড 3 (বা এখনও 2 ...) সিঙ্ক্রোনাইজড ব্লকে প্রবেশ করে। Ekক! এটি মনে করে যে এটি ভাগ করা ডেটাতে এক্সক্লুসিভ অ্যাক্সেস পেয়েছে তবে থ্রেড 1 এর সাথে এটি এখনও উত্তেজনাকর ...

আপনি কেন এমনটি হতে চান ? সম্ভবত কিছু বিশেষায়িত পরিস্থিতি রয়েছে যেখানে এটি বোধগম্য হয় ... তবে আমি খুশি হতে পারার আগে আপনি আমাকে একটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে (আমার উপরের দৃশ্যের ধরণের প্রশস্তকরণের উপায়গুলি সহ) উপস্থাপন করতে হবে এটা।

Question 4

আমি জন এর মন্তব্যের সাথে একমত: আপনার ভেরিয়েবলের রেফারেন্স পরিবর্তনের ক্ষেত্রে অসামঞ্জস্যতা রোধ করতে একটি চূড়ান্ত লক ডামি ব্যবহার করার সময় আপনাকে সর্বদা চূড়ান্ত লক ডামি ব্যবহার করতে হবে । সুতরাং যে কোনও ক্ষেত্রে এবং থাম্বের প্রথম নিয়ম হিসাবে:

নিয়ম # 1: ক্ষেত্রটি চূড়ান্ত না হলে সর্বদা একটি (ব্যক্তিগত) চূড়ান্ত লক ডামি ব্যবহার করুন।

কারণ # 1: আপনি লকটি ধরে রেখে ভেরিয়েবলের রেফারেন্সটি নিজেই পরিবর্তন করেন। সিঙ্ক্রোনাইজড লকের বাইরে অপেক্ষা করা অন্য একটি থ্রেড সুরক্ষিত ব্লকে প্রবেশ করতে সক্ষম হবে।

কারণ # 2: আপনি লকটি ধরে রেখেছেন এবং অন্য একটি থ্রেড ভেরিয়েবলের রেফারেন্স পরিবর্তন করে। ফলাফল একই: অন্য থ্রেড রক্ষিত ব্লকে প্রবেশ করতে পারে।

তবে চূড়ান্ত লক ডামি ব্যবহার করার সময়, আরও একটি সমস্যা রয়েছে : আপনি ভুল ডেটা পেতে পারেন, কারণ আপনার অ-চূড়ান্ত অবজেক্টটি কেবল সিঙ্ক্রোনাইজ (অবজেক্ট) কল করার সময় র‌্যামের সাথে সিঙ্ক্রোনাইজ হবে। সুতরাং, থাম্বের দ্বিতীয় নিয়ম হিসাবে:

বিধি # 2: একটি চূড়ান্ত নয় এমন অবজেক্টটি লক করার সময় আপনাকে উভয়ই করতে হবে: র‌্যাম সিঙ্ক্রোনাইজেশনের জন্য চূড়ান্ত লক ডামি এবং চূড়ান্ত অবজেক্টের লকটি ব্যবহার করা। (একমাত্র বিকল্প হ'ল বস্তুর সমস্ত ক্ষেত্রকে অস্থির হিসাবে ঘোষণা করা হবে!)

এই লকগুলি "নেস্টেড লকস" নামেও পরিচিত। নোট করুন যে আপনাকে অবশ্যই সর্বদা একই ক্রমে কল করতে হবে, অন্যথায় আপনি একটি মৃত লক পাবেন :

public class X {
    private final LOCK;
    private Object o;

    public void setO(Object o){
        this.o = o;  
    }  

    public void x() {
        synchronized (LOCK) {
        synchronized(o){
            //do something with o...
        }
        }  
    }  
}

আপনি দেখতে পাচ্ছেন যে আমি দুটি লকটি সরাসরি একই লাইনে লিখি কারণ তারা সর্বদা এক সাথে থাকে। এটির মতো, আপনি এমনকি 10 টি নেস্টিং লকও করতে পারেন:

synchronized (LOCK1) {
synchronized (LOCK2) {
synchronized (LOCK3) {
synchronized (LOCK4) {
    //entering the locked space
}
}
}
}

মনে রাখবেন যে আপনি যদি synchronized (LOCK3)অন্য থ্রেডের মতো কেবল একটি অভ্যন্তরীণ লক অর্জন করেন তবে এই কোডটি ভাঙবে না । আপনি যদি অন্য থ্রেডে এরকম কিছু কল করেন তবে এটি ভেঙে যাবে:

synchronized (LOCK4) {
synchronized (LOCK1) {  //dead lock!
synchronized (LOCK3) {
synchronized (LOCK2) {
    //will never enter here...
}
}
}
}

চূড়ান্ত নয় এমন ক্ষেত্রগুলি পরিচালনা করার সময় যেমন নেস্টেড লকগুলির চারপাশে কেবলমাত্র একটি কাজ রয়েছে:

বিধি # 2 - বিকল্প: বস্তুর সমস্ত ক্ষেত্রকে অস্থির হিসাবে ঘোষণা করুন। (আমি এখানে এটি করার অসুবিধাগুলি সম্পর্কে কথা বলব না, উদাহরণস্বরূপ পাঠের ক্ষেত্রেও এক্স-লেভেল ক্যাশে থাকা কোনও স্টোরেজ প্রতিরোধ করা))

সুতরাং আইওউবটি বেশ সঠিক: কেবল java.util.concurrent ব্যবহার করুন। অথবা সিঙ্ক্রোনাইজেশন সম্পর্কে সমস্ত কিছু বুঝতে শুরু করুন এবং নেস্টেড লকগুলি দিয়ে নিজেই এটি করুন। ;)

চূড়ান্ত নয় এমন ক্ষেত্রগুলিতে কেন সিঙ্ক্রোনাইজেশন বিরতি দেয় সে সম্পর্কে আরও তথ্যের জন্য আমার পরীক্ষার কেসটি দেখুন: https://stackoverflow.com/a/21460055/2012947

এবং র‍্যাম এবং ক্যাশেগুলির কারণে আপনাকে কেন একেবারে সিঙ্ক্রোনাইজ করা দরকার তা আরও বিশদের জন্য এখানে দেখুন: https://stackoverflow.com/a/21409975/2012947

Question 5

আমি এখানে সত্যিকারের সঠিক উত্তরটি দেখছি না, এটি করার পক্ষে এটি পুরোপুরি ঠিক।

আমি কেন নিশ্চিত হলাম না কেন এটি একটি সতর্কতা, এতে কোনও ভুল নেই। জেভিএম যে আপনি পেতে নিশ্চিত করে তোলে কিছু বৈধ বস্তু ফিরে (অথবা নাল) আপনি যখন একটি মান পড়ুন, এবং আপনার উপর সিংক্রোনাইজ করতে পারেন কোন বস্তুর সাথে ।

আপনি যদি লকটি ব্যবহারের সময় প্রকৃতপক্ষে পরিবর্তনের পরিকল্পনা করেন (উদাহরণস্বরূপ, এটি ব্যবহার শুরু করার আগে কোনও init পদ্ধতি থেকে এটি পরিবর্তন করার বিপরীতে), আপনার যে পরিবর্তনটি পরিবর্তন করার পরিকল্পনা রয়েছে তা আপনাকে করতে হবে volatile। তারপরে আপনাকে যা করতে হবে তা হ'ল পুরানো এবং নতুন উভয় বস্তুর সমন্বয় করা এবং আপনি নিরাপদে মানটি পরিবর্তন করতে পারেন

public volatile Object lock;

...

synchronized (lock) {
    synchronized (newObject) {
        lock = newObject;
    }
}

সেখানে এটি জটিল নয়, লক্সের সাথে কোড লিখতে (মিটেক্সেস) আসলে বেশ সহজ। তাদের ছাড়াই কোড লিখন (লক ফ্রি কোড) যা কঠিন।

Question 6

সম্পাদনা: সুতরাং এই সমাধানটিতে (জন স্কিটির পরামর্শ অনুসারে) "সিঙ্ক্রোনাইজড (অবজেক্ট) implementation}" প্রয়োগের পরমাণুর সাথে একটি সমস্যা থাকতে পারে যখন অবজেক্টের রেফারেন্স পরিবর্তন হচ্ছে। আমি পৃথকভাবে জিজ্ঞাসা করেছি এবং মিঃ এরিকসনের মতে এটি থ্রেড নিরাপদ নয় - দেখুন: সিঙ্ক্রোনাইজড ব্লক পারমাণবিক প্রবেশ করছে? । সুতরাং এটি কীভাবে করবেন না তা উদাহরণ হিসাবে গ্রহণ করুন - কেন লিঙ্কগুলি সহ;)

কোডটি দেখুন কীভাবে এটি কাজ করবে যদি সিঙ্ক্রোনাইজ করা হয় () পারমাণবিক হবে:

public class Main {
    static class Config{
        char a='0';
        char b='0';
        public void log(){
            synchronized(this){
                System.out.println(""+a+","+b);
            }
        }
    }

    static Config cfg = new Config();

    static class Doer extends Thread {
        char id;

        Doer(char id) {
            this.id = id;
        }

        public void mySleep(long ms){
            try{Thread.sleep(ms);}catch(Exception ex){ex.printStackTrace();}
        }

        public void run() {
            System.out.println("Doer "+id+" beg");
            if(id == 'X'){
                synchronized (cfg){
                    cfg.a=id;
                    mySleep(1000);
                    // do not forget to put synchronize(cfg) over setting new cfg - otherwise following will happend
                    // here it would be modifying different cfg (cos Y will change it).
                    // Another problem would be that new cfg would be in parallel modified by Z cos synchronized is applied on new object
                    cfg.b=id;
                }
            }
            if(id == 'Y'){
                mySleep(333);
                synchronized(cfg) // comment this and you will see inconsistency in log - if you keep it I think all is ok
                {
                    cfg = new Config();  // introduce new configuration
                    // be aware - don't expect here to be synchronized on new cfg!
                    // Z might already get a lock
                }
            }
            if(id == 'Z'){
                mySleep(666);
                synchronized (cfg){
                    cfg.a=id;
                    mySleep(100);
                    cfg.b=id;
                }
            }
            System.out.println("Doer "+id+" end");
            cfg.log();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Doer X = new Doer('X');
        Doer Y = new Doer('Y');
        Doer Z = new Doer('Z');
        X.start();
        Y.start();
        Z.start();
    }

}

Question 7

আপনার প্রয়োজনীয়তার জন্য অ্যাটমিক রেফারেন্স স্যুট।

পারমাণবিক প্যাকেজ সম্পর্কে জাভা নথি থেকে :

ক্লাসগুলির একটি ছোট টুলকিট যা একক ভেরিয়েবলগুলিতে লক-ফ্রি থ্রেড-নিরাপদ প্রোগ্রামিং সমর্থন করে। সংক্ষেপে, এই প্যাকেজের ক্লাসগুলি সেই ফলের একটি পারমাণবিক শর্তসাপেক্ষ আপডেট অপারেশন সরবরাহকারীদের জন্য উদ্বায়ী মান, ক্ষেত্র এবং অ্যারে উপাদানগুলির ধারণা বাড়িয়ে তোলে:

boolean compareAndSet(expectedValue, updateValue);

কোডের উদাহরণ:

String initialReference = "value 1";

AtomicReference<String> someRef =
    new AtomicReference<String>(initialReference);

String newReference = "value 2";
boolean exchanged = someRef.compareAndSet(initialReference, newReference);
System.out.println("exchanged: " + exchanged);

উপরের উদাহরণে, আপনি প্রতিস্থাপন করুন String নিজের সাথে করুনObject

সম্পর্কিত এসই প্রশ্ন:

জাভাতে কখন অ্যাটমিক রেফারেন্স ব্যবহার করবেন?

Question 8

যদি oএকটি দৃষ্টান্ত এর জীবনকাল জন্য কখনোই পরিবর্তনX তবে দ্বিতীয় সংস্করণ সিঙ্ক্রোনাইজেশন জড়িত কিনা তা নির্বিশেষে ভাল স্টাইল।

এখন, প্রথম সংস্করণে কিছু ভুল আছে কিনা সেই ক্লাসে আর কী চলছে তা জেনেও উত্তর দেওয়া অসম্ভব। আমি সংকলকটির সাথে একমত হতে চাই যে এটি ত্রুটি-প্রবণ দেখায় (অন্যরা যা বলেছিল আমি তার পুনরাবৃত্তি করব না)।

Question 9

কেবল আমার দুটি সেন্ট যুক্ত করুন: আমি যখন এই ডিজাইনারের মাধ্যমে তাত্ক্ষণিকভাবে উপাদান ব্যবহার করি তখন আমার এই সতর্কতা ছিল, সুতরাং ক্ষেত্রটি সত্যই চূড়ান্ত হতে পারে না, কারণ নির্মাণকারী পরামিতি নিতে পারে না। অন্য কথায়, আমার চূড়ান্ত কীওয়ার্ড ছাড়াই কোয়াস্ট ফাইনাল ফিল্ড ছিল।

আমি মনে করি সে কারণেই এটি কেবল সতর্ক করা হচ্ছে: আপনি সম্ভবত কিছু ভুল করছেন তবে এটি সম্ভবত সঠিকও হতে পারে।