Mengapa kunci (ini) {...} buruk?

The dokumentasi MSDN mengatakan bahwa

public class SomeObject
{
  public void SomeOperation()
  {
    lock(this)
    {
      //Access instance variables
    }
  }
}

adalah "masalah jika instance dapat diakses secara publik". Saya bertanya-tanya mengapa? Apakah karena kunci akan ditahan lebih lama dari yang diperlukan? Atau adakah alasan yang lebih berbahaya?

Ini adalah bentuk yang buruk untuk digunakan thisdalam pernyataan kunci karena umumnya di luar kendali Anda siapa lagi yang mungkin mengunci objek itu.

Untuk merencanakan operasi paralel dengan semestinya, perhatian khusus harus diberikan untuk mempertimbangkan kemungkinan situasi jalan buntu, dan memiliki jumlah titik masuk kunci yang tidak diketahui menghalangi hal ini. Misalnya, siapa pun yang memiliki referensi ke objek dapat menguncinya tanpa perancang / pembuat objek mengetahuinya. Ini meningkatkan kompleksitas solusi multi-utas dan mungkin memengaruhi kebenarannya.

Bidang pribadi biasanya merupakan opsi yang lebih baik karena kompiler akan memberlakukan pembatasan akses padanya, dan itu akan merangkum mekanisme penguncian. Menggunakan thismelanggar enkapsulasi dengan memaparkan sebagian dari implementasi penguncian Anda kepada publik. Juga tidak jelas bahwa Anda akan mendapatkan kunci thiskecuali jika telah didokumentasikan. Bahkan kemudian, mengandalkan dokumentasi untuk mencegah masalah tidak optimal.

Akhirnya, ada kesalahpahaman umum yang lock(this)benar - benar memodifikasi objek yang dilewatkan sebagai parameter, dan dalam beberapa cara membuatnya hanya-baca atau tidak dapat diakses. Ini salah . Objek diteruskan sebagai parameter lockhanya berfungsi sebagai kunci . Jika kunci sudah ditahan pada kunci itu, kunci tidak dapat dibuat; jika tidak, kunci diizinkan.

Inilah sebabnya mengapa buruk untuk menggunakan string sebagai kunci dalam lockpernyataan, karena mereka tidak dapat diubah dan dibagikan / diakses di seluruh bagian aplikasi. Anda harus menggunakan variabel pribadi sebagai gantinya, sebuah Objectinstance akan melakukannya dengan baik.

Jalankan kode C # berikut sebagai contoh.

public class Person
{
    public int Age { get; set;  }
    public string Name { get; set; }

    public void LockThis()
    {
        lock (this)
        {
            System.Threading.Thread.Sleep(10000);
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        var nancy = new Person {Name = "Nancy Drew", Age = 15};
        var a = new Thread(nancy.LockThis);
        a.Start();
        var b = new Thread(Timewarp);
        b.Start(nancy);
        Thread.Sleep(10);
        var anotherNancy = new Person { Name = "Nancy Drew", Age = 50 };
        var c = new Thread(NameChange);
        c.Start(anotherNancy);
        a.Join();
        Console.ReadLine();
    }

    static void Timewarp(object subject)
    {
        var person = subject as Person;
        if (person == null) throw new ArgumentNullException("subject");
        // A lock does not make the object read-only.
        lock (person.Name)
        {
            while (person.Age <= 23)
            {
                // There will be a lock on 'person' due to the LockThis method running in another thread
                if (Monitor.TryEnter(person, 10) == false)
                {
                    Console.WriteLine("'this' person is locked!");
                }
                else Monitor.Exit(person);
                person.Age++;
                if(person.Age == 18)
                {
                    // Changing the 'person.Name' value doesn't change the lock...
                    person.Name = "Nancy Smith";
                }
                Console.WriteLine("{0} is {1} years old.", person.Name, person.Age);
            }
        }
    }

    static void NameChange(object subject)
    {
        var person = subject as Person;
        if (person == null) throw new ArgumentNullException("subject");
        // You should avoid locking on strings, since they are immutable.
        if (Monitor.TryEnter(person.Name, 30) == false)
        {
            Console.WriteLine("Failed to obtain lock on 50 year old Nancy, because Timewarp(object) locked on string \"Nancy Drew\".");
        }
        else Monitor.Exit(person.Name);

        if (Monitor.TryEnter("Nancy Drew", 30) == false)
        {
            Console.WriteLine("Failed to obtain lock using 'Nancy Drew' literal, locked by 'person.Name' since both are the same object thanks to inlining!");
        }
        else Monitor.Exit("Nancy Drew");
        if (Monitor.TryEnter(person.Name, 10000))
        {
            string oldName = person.Name;
            person.Name = "Nancy Callahan";
            Console.WriteLine("Name changed from '{0}' to '{1}'.", oldName, person.Name);
        }
        else Monitor.Exit(person.Name);
    }
}

Output konsol

'this' person is locked!
Nancy Drew is 16 years old.
'this' person is locked!
Nancy Drew is 17 years old.
Failed to obtain lock on 50 year old Nancy, because Timewarp(object) locked on string "Nancy Drew".
'this' person is locked!
Nancy Smith is 18 years old.
'this' person is locked!
Nancy Smith is 19 years old.
'this' person is locked!
Nancy Smith is 20 years old.
Failed to obtain lock using 'Nancy Drew' literal, locked by 'person.Name' since both are the same object thanks to inlining!
'this' person is locked!
Nancy Smith is 21 years old.
'this' person is locked!
Nancy Smith is 22 years old.
'this' person is locked!
Nancy Smith is 23 years old.
'this' person is locked!
Nancy Smith is 24 years old.
Name changed from 'Nancy Drew' to 'Nancy Callahan'.

Karena jika orang bisa mendapatkan thispointer objek Anda (yaitu: Anda ), maka mereka juga dapat mencoba untuk mengunci objek yang sama. Sekarang mereka mungkin tidak menyadari bahwa Anda mengunci secara thisinternal, jadi ini dapat menyebabkan masalah (mungkin jalan buntu)

Selain itu, ini juga praktik yang buruk, karena mengunci "terlalu banyak"

Misalnya, Anda mungkin memiliki variabel anggota List<int>, dan satu-satunya hal yang perlu Anda kunci adalah variabel anggota itu. Jika Anda mengunci seluruh objek di fungsi Anda, maka hal-hal lain yang memanggil fungsi-fungsi itu akan diblokir menunggu kunci. Jika fungsi-fungsi itu tidak perlu mengakses daftar anggota, Anda akan menyebabkan kode lain menunggu dan memperlambat aplikasi Anda tanpa alasan sama sekali.

Lihatlah Sinkronisasi Topik MSDN (Panduan Pemrograman C #)

Secara umum, yang terbaik adalah menghindari penguncian pada tipe publik, atau pada instance objek di luar kendali aplikasi Anda. Sebagai contoh, kunci (ini) dapat menjadi masalah jika instance dapat diakses secara publik, karena kode di luar kendali Anda dapat mengunci objek juga. Ini bisa menciptakan situasi jalan buntu di mana dua atau lebih utas menunggu rilis objek yang sama. Mengunci tipe data publik, yang bertentangan dengan objek, dapat menyebabkan masalah karena alasan yang sama. Mengunci string literal sangat berisiko karena string literal diinternir oleh runtime bahasa umum (CLR). Ini berarti bahwa ada satu contoh string string apa pun yang diberikan untuk seluruh program, objek yang sama persis mewakili literal di semua domain aplikasi yang berjalan, di semua utas. Akibatnya, kunci ditempatkan pada string dengan konten yang sama di mana saja dalam proses aplikasi mengunci semua contoh string itu dalam aplikasi. Akibatnya, yang terbaik adalah mengunci anggota pribadi atau yang dilindungi yang tidak diinternir. Beberapa kelas menyediakan anggota khusus untuk mengunci. Jenis Array, misalnya, menyediakan SyncRoot. Banyak tipe koleksi menyediakan anggota SyncRoot juga.

Saya tahu ini adalah utas lama, tetapi karena orang masih dapat melihat dan mengandalkannya, sepertinya penting untuk menunjukkan bahwa lock(typeof(SomeObject))ini jauh lebih buruk daripada lock(this). Setelah mengatakan itu; pujian tulus kepada Alan karena menunjukkan bahwa itu lock(typeof(SomeObject))adalah praktik yang buruk.

Sebuah instance dari System.Typeadalah salah satu objek yang paling umum, berbutir kasar. Paling tidak, turunan dari System.Type bersifat global ke suatu AppDomain, dan .NET dapat menjalankan banyak program dalam suatu AppDomain. Ini berarti bahwa dua program yang sama sekali berbeda berpotensi menyebabkan gangguan dalam satu sama lain bahkan sampai membuat jalan buntu jika mereka berdua mencoba untuk mendapatkan kunci sinkronisasi pada instance jenis yang sama.

Jadi lock(this)bukan bentuk yang kuat, dapat menyebabkan masalah dan harus selalu mengangkat alis karena semua alasan yang dikutip. Namun ada banyak kode yang digunakan, relatif dihormati dan tampaknya stabil seperti log4net yang menggunakan pola kunci (ini) secara luas, meskipun saya pribadi lebih suka melihat perubahan pola itu.

Tapi lock(typeof(SomeObject))membuka kaleng cacing yang sama sekali baru dan lebih baik.

Untuk apa nilainya.

... dan argumen yang sama persis berlaku untuk konstruk ini juga:

lock(typeof(SomeObject))

Bayangkan Anda memiliki sekretaris yang terampil di kantor Anda yang merupakan sumber daya bersama di departemen. Sesekali, Anda bergegas ke arah mereka karena Anda memiliki tugas, hanya untuk berharap bahwa rekan kerja Anda yang lain belum mengklaimnya. Biasanya Anda hanya perlu menunggu untuk jangka waktu singkat.

Karena kepedulian berbagi, manajer Anda memutuskan bahwa pelanggan dapat menggunakan sekretaris secara langsung juga. Tetapi ini memiliki efek samping: Seorang pelanggan bahkan mungkin mengklaim mereka saat Anda sedang bekerja untuk pelanggan ini dan Anda juga membutuhkan mereka untuk melaksanakan bagian dari tugas. Kebuntuan terjadi, karena klaim bukan lagi hierarki. Ini bisa dihindari bersama-sama dengan tidak membiarkan pelanggan mengklaimnya sejak awal.

lock(this)buruk seperti yang kita lihat. Objek luar mungkin mengunci objek dan karena Anda tidak mengontrol siapa yang menggunakan kelas, siapa pun dapat menguncinya ... Yang merupakan contoh tepat seperti dijelaskan di atas. Sekali lagi, solusinya adalah membatasi pemaparan objek. Namun, jika Anda memiliki private, protectedatau internalkelas, Anda sudah bisa mengendalikan siapa yang mengunci objek Anda , karena Anda yakin telah menulis kode sendiri. Jadi pesannya di sini adalah: jangan memaparkannya sebagai public. Juga, memastikan bahwa kunci digunakan dalam skenario yang sama menghindari kebuntuan.

Kebalikan dari ini adalah untuk mengunci sumber daya yang dibagikan di seluruh domain aplikasi - skenario terburuk. Ini seperti menempatkan sekretaris Anda di luar dan membiarkan semua orang di luar sana mengklaimnya. Hasilnya adalah kekacauan total - atau dalam hal kode sumber: itu adalah ide yang buruk; buang dan mulai lagi dari awal. Jadi bagaimana kita melakukannya?

Jenis dibagi dalam domain aplikasi seperti yang ditunjukkan sebagian besar orang di sini. Tetapi ada hal-hal yang lebih baik yang dapat kita gunakan: string. Alasannya adalah bahwa string dikumpulkan . Dengan kata lain: jika Anda memiliki dua string yang memiliki konten yang sama di domain aplikasi, ada kemungkinan bahwa mereka memiliki pointer yang sama persis. Karena pointer digunakan sebagai kunci kunci, yang pada dasarnya Anda dapatkan adalah sinonim untuk "mempersiapkan perilaku yang tidak terdefinisi".

Demikian pula, Anda tidak harus mengunci objek WCF, HttpContext.Current, Thread.Current, Singletons (secara umum), dll. Cara termudah untuk menghindari semua ini? private [static] object myLock = new object();

Mengunci pointer ini bisa buruk jika Anda mengunci sumber daya bersama . Sumber daya yang dibagikan dapat berupa variabel statis atau file di komputer Anda - yaitu sesuatu yang dibagikan di antara semua pengguna kelas. Alasannya adalah bahwa pointer ini akan berisi referensi yang berbeda ke lokasi di memori setiap kali kelas Anda dipakai. Jadi, mengunci ini sekaligus contoh kelas berbeda dari mengunci ini pada instance lain dari suatu kelas.

Lihat kode ini untuk melihat apa yang saya maksud. Tambahkan kode berikut ke program utama Anda di aplikasi Konsol:

    static void Main(string[] args)
    {
         TestThreading();
         Console.ReadLine();
    }

    public static void TestThreading()
    {
        Random rand = new Random();
        Thread[] threads = new Thread[10];
        TestLock.balance = 100000;
        for (int i = 0; i < 10; i++)
        {
            TestLock tl = new TestLock();
            Thread t = new Thread(new ThreadStart(tl.WithdrawAmount));
            threads[i] = t;
        }
        for (int i = 0; i < 10; i++)
        {
            threads[i].Start();
        }
        Console.Read();
    }

Buat kelas baru seperti di bawah ini.

 class TestLock
{
    public static int balance { get; set; }
    public static readonly Object myLock = new Object();

    public void Withdraw(int amount)
    {
      // Try both locks to see what I mean
      //             lock (this)
       lock (myLock)
        {
            Random rand = new Random();
            if (balance >= amount)
            {
                Console.WriteLine("Balance before Withdrawal :  " + balance);
                Console.WriteLine("Withdraw        : -" + amount);
                balance = balance - amount;
                Console.WriteLine("Balance after Withdrawal  :  " + balance);
            }
            else
            {
                Console.WriteLine("Can't process your transaction, current balance is :  " + balance + " and you tried to withdraw " + amount);
            }
        }

    }
    public void WithdrawAmount()
    {
        Random rand = new Random();
        Withdraw(rand.Next(1, 100) * 100);
    }
}

Berikut ini adalah program penguncian ini .

   Balance before Withdrawal :  100000
    Withdraw        : -5600
    Balance after Withdrawal  :  94400
    Balance before Withdrawal :  100000
    Balance before Withdrawal :  100000
    Withdraw        : -5600
    Balance after Withdrawal  :  88800
    Withdraw        : -5600
    Balance after Withdrawal  :  83200
    Balance before Withdrawal :  83200
    Withdraw        : -9100
    Balance after Withdrawal  :  74100
    Balance before Withdrawal :  74100
    Withdraw        : -9100
    Balance before Withdrawal :  74100
    Withdraw        : -9100
    Balance after Withdrawal  :  55900
    Balance after Withdrawal  :  65000
    Balance before Withdrawal :  55900
    Withdraw        : -9100
    Balance after Withdrawal  :  46800
    Balance before Withdrawal :  46800
    Withdraw        : -2800
    Balance after Withdrawal  :  44000
    Balance before Withdrawal :  44000
    Withdraw        : -2800
    Balance after Withdrawal  :  41200
    Balance before Withdrawal :  44000
    Withdraw        : -2800
    Balance after Withdrawal  :  38400

Berikut ini adalah program penguncian di myLock .

Balance before Withdrawal :  100000
Withdraw        : -6600
Balance after Withdrawal  :  93400
Balance before Withdrawal :  93400
Withdraw        : -6600
Balance after Withdrawal  :  86800
Balance before Withdrawal :  86800
Withdraw        : -200
Balance after Withdrawal  :  86600
Balance before Withdrawal :  86600
Withdraw        : -8500
Balance after Withdrawal  :  78100
Balance before Withdrawal :  78100
Withdraw        : -8500
Balance after Withdrawal  :  69600
Balance before Withdrawal :  69600
Withdraw        : -8500
Balance after Withdrawal  :  61100
Balance before Withdrawal :  61100
Withdraw        : -2200
Balance after Withdrawal  :  58900
Balance before Withdrawal :  58900
Withdraw        : -2200
Balance after Withdrawal  :  56700
Balance before Withdrawal :  56700
Withdraw        : -2200
Balance after Withdrawal  :  54500
Balance before Withdrawal :  54500
Withdraw        : -500
Balance after Withdrawal  :  54000

Ada artikel yang sangat bagus tentang hal itu http://bytes.com/topic/c-sharp/answers/249277-dont-lock-type-objects oleh Rico Mariani, arsitek kinerja untuk runtime Microsoft® .NET

Kutipan:

Masalah mendasar di sini adalah bahwa Anda tidak memiliki objek jenis, dan Anda tidak tahu siapa lagi yang bisa mengaksesnya. Secara umum, ini adalah ide yang sangat buruk untuk mengandalkan mengunci objek yang tidak Anda buat dan tidak tahu siapa lagi yang mengakses. Melakukan hal itu mengundang kebuntuan. Cara teraman adalah dengan hanya mengunci objek pribadi.

Ada juga beberapa diskusi bagus tentang ini di sini: Apakah ini penggunaan yang tepat dari sebuah mutex?

Berikut adalah ilustrasi yang jauh lebih sederhana (diambil dari Pertanyaan 34 di sini ) mengapa kunci (ini) buruk dan dapat mengakibatkan kebuntuan ketika konsumen kelas Anda juga mencoba untuk mengunci objek. Di bawah ini, hanya satu dari tiga utas yang dapat dilanjutkan, dua lainnya mengalami kebuntuan.

class SomeClass
{
    public void SomeMethod(int id)
    {
        **lock(this)**
        {
            while(true)
            {
                Console.WriteLine("SomeClass.SomeMethod #" + id);
            }
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        SomeClass o = new SomeClass();

        lock(o)
        {
            for (int threadId = 0; threadId < 3; threadId++)
            {
                Thread t = new Thread(() => {
                    o.SomeMethod(threadId);
                        });
                t.Start();
            }

            Console.WriteLine();
        }

Untuk menyiasatinya, orang ini menggunakan Thread.TryMonitor (dengan waktu habis) alih-alih mengunci:

            Monitor.TryEnter(temp, millisecondsTimeout, ref lockWasTaken);
            if (lockWasTaken)
            {
                doAction();
            }
            else
            {
                throw new Exception("Could not get lock");
            }

https://blogs.appbeat.io/post/c-how-to-lock-without-deadlocks

Karena setiap potongan kode yang dapat melihat instance kelas Anda juga dapat mengunci referensi itu. Anda ingin menyembunyikan (mengenkapsulasi) objek penguncian Anda sehingga hanya kode yang perlu referensi yang dapat merujuknya. Kata kunci ini merujuk pada turunan kelas saat ini, sehingga sejumlah hal dapat merujuknya dan dapat menggunakannya untuk melakukan sinkronisasi utas.

Agar jelas, ini buruk karena beberapa potongan kode lain dapat menggunakan instance kelas untuk mengunci, dan mungkin mencegah kode Anda mendapatkan kunci tepat waktu atau dapat membuat masalah sinkronisasi utas lainnya. Kasus terbaik: tidak ada lagi yang menggunakan referensi ke kelas Anda untuk mengunci. Huruf tengah: sesuatu menggunakan referensi ke kelas Anda untuk melakukan penguncian dan itu menyebabkan masalah kinerja. Kasus terburuk: sesuatu menggunakan referensi kelas Anda untuk melakukan penguncian dan itu menyebabkan masalah yang sangat buruk, sangat halus, sangat sulit untuk di-debug.

Maaf teman-teman tapi saya tidak setuju dengan argumen bahwa mengunci ini dapat menyebabkan kebuntuan. Anda membingungkan dua hal: jalan buntu dan kelaparan.

• Anda tidak dapat membatalkan kebuntuan tanpa mengganggu salah satu utas jadi setelah Anda memasuki kebuntuan Anda tidak bisa keluar
• Kelaparan akan berakhir secara otomatis setelah salah satu utas menyelesaikan tugasnya

Berikut adalah gambar yang menggambarkan perbedaannya.

Kesimpulan
Anda masih dapat menggunakan dengan aman lock(this)jika kekosongan utas bukan masalah bagi Anda. Anda masih harus ingat bahwa ketika utas, yaitu utas kelaparan menggunakan lock(this)ujung dalam kunci yang mengunci objek Anda, akhirnya akan berakhir pada kelaparan abadi;)

Silakan merujuk ke tautan berikut yang menjelaskan mengapa kunci (ini) bukan ide yang baik.

http://blogs.msdn.com/b/bclteam/archive/2004/01/20/60719.aspx

Jadi solusinya adalah menambahkan objek pribadi, misalnya, lockObject ke kelas dan tempatkan wilayah kode di dalam pernyataan kunci seperti yang ditunjukkan di bawah ini:

lock (lockObject)
{
...
}

Berikut ini beberapa contoh kode yang lebih mudah diikuti (IMO): (Akan berfungsi di LinqPad , rujuk ruang nama berikut: System.Net dan System.Threading.Tasks)

Yang perlu diingat adalah kunci itu (x) pada dasarnya adalah gula sintaksis dan apa yang dilakukannya adalah menggunakan Monitor. Masukkan dan kemudian gunakan coba, tangkap, akhirnya blokir untuk memanggil Monitor. Keluar. Lihat: https://docs.microsoft.com/en-us/dotnet/api/system.threading.monitor.enter (bagian keterangan)

atau gunakan pernyataan kunci C # (pernyataan SyncLock dalam Visual Basic), yang membungkus metode Enter dan Exit dalam blok coba… akhirnya.

void Main()
{
    //demonstrates why locking on THIS is BADD! (you should never lock on something that is publicly accessible)
    ClassTest test = new ClassTest();
    lock(test) //locking on the instance of ClassTest
    {
        Console.WriteLine($"CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        Parallel.Invoke(new Action[]
        {
            () => {
                //this is there to just use up the current main thread. 
                Console.WriteLine($"CurrentThread {Thread.CurrentThread.ManagedThreadId}");
                },
            //none of these will enter the lock section.
            () => test.DoWorkUsingThisLock(1),//this will dead lock as lock(x) uses Monitor.Enter
            () => test.DoWorkUsingMonitor(2), //this will not dead lock as it uses Montory.TryEnter
        });
    }
}

public class ClassTest
{
    public void DoWorkUsingThisLock(int i)
    {
        Console.WriteLine($"Start ClassTest.DoWorkUsingThisLock {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        lock(this) //this can be bad if someone has locked on this already, as it will cause it to be deadlocked!
        {
            Console.WriteLine($"Running: ClassTest.DoWorkUsingThisLock {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
            Thread.Sleep(1000);
        }
        Console.WriteLine($"End ClassTest.DoWorkUsingThisLock Done {i}  CurrentThread {Thread.CurrentThread.ManagedThreadId}");
    }

    public void DoWorkUsingMonitor(int i)
    {
        Console.WriteLine($"Start ClassTest.DoWorkUsingMonitor {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        if (Monitor.TryEnter(this))
        {
            Console.WriteLine($"Running: ClassTest.DoWorkUsingMonitor {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
            Thread.Sleep(1000);
            Monitor.Exit(this);
        }
        else
        {
            Console.WriteLine($"Skipped lock section!  {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        }

        Console.WriteLine($"End ClassTest.DoWorkUsingMonitor Done {i} CurrentThread {Thread.CurrentThread.ManagedThreadId}");
        Console.WriteLine();
    }
}

Keluaran

CurrentThread 15
CurrentThread 15
Start ClassTest.DoWorkUsingMonitor 2 CurrentThread 13
Start ClassTest.DoWorkUsingThisLock 1 CurrentThread 12
Skipped lock section!  2 CurrentThread 13
End ClassTest.DoWorkUsingMonitor Done 2 CurrentThread 13

Perhatikan bahwa Thread # 12 tidak pernah berakhir karena mati terkunci.

Anda bisa menetapkan aturan yang mengatakan bahwa kelas bisa memiliki kode yang mengunci 'ini' atau objek apa pun yang kode di kelas instantiate. Jadi itu hanya masalah jika polanya tidak diikuti.

Jika Anda ingin melindungi diri dari kode yang tidak mengikuti pola ini, maka jawaban yang diterima benar. Tetapi jika polanya diikuti, itu tidak masalah.

Keuntungan dari penguncian (ini) adalah efisiensi. Bagaimana jika Anda memiliki "objek nilai" sederhana yang memiliki nilai tunggal. Itu hanya pembungkus, dan akan dipakai jutaan kali. Dengan meminta pembuatan objek sinkronisasi pribadi hanya untuk mengunci, Anda pada dasarnya telah menggandakan ukuran objek dan menggandakan jumlah alokasi. Ketika masalah kinerja, ini adalah keuntungan.

Ketika Anda tidak peduli dengan jumlah alokasi atau jejak memori, menghindari kunci (ini) lebih disukai karena alasan yang ditunjukkan dalam jawaban lain.

Akan ada masalah jika instance dapat diakses secara publik karena mungkin ada permintaan lain yang mungkin menggunakan instance objek yang sama. Lebih baik menggunakan variabel pribadi / statis.