Tuyên bố miễn trừ trách nhiệm: Tôi vừa tóm tắt tất cả các câu trả lời tuyệt vời và viết nó bằng lời của tôi.
Trong khi triển khai Singleton, chúng tôi có 2 tùy chọn
1. Tải nhanh
2. Tải sớm
Tải lười biếng thêm chi phí bit (rất nhiều thành thật) vì vậy chỉ sử dụng nó khi bạn có một đối tượng rất lớn hoặc mã xây dựng nặng VÀ cũng có các phương thức hoặc trường tĩnh có thể truy cập khác có thể được sử dụng trước khi cần một thể hiện, sau đó và chỉ sau đó bạn cần sử dụng khởi tạo lười biếng. Mặt khác, chọn tải sớm là một lựa chọn tốt.
Cách đơn giản nhất để thực hiện Singleton là
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
}
Tất cả mọi thứ là tốt ngoại trừ singleton tải sớm của nó. Hãy thử singleton tải lười biếng
class Foo {
// Our now_null_but_going_to_be sole hero
private static Foo INSTANCE = null;
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
// Creating only when required.
if (INSTANCE == null) {
INSTANCE = new Foo();
}
return INSTANCE;
}
}
Cho đến nay rất tốt nhưng anh hùng của chúng ta sẽ không sống sót khi chiến đấu một mình với nhiều chủ đề xấu xa, những người muốn có nhiều ví dụ về anh hùng của chúng ta. Vì vậy, hãy bảo vệ nó khỏi luồng đa luồng xấu xa
class Foo {
private static Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
// No more tension of threads
synchronized (Foo.class) {
if (INSTANCE == null) {
INSTANCE = new Foo();
}
}
return INSTANCE;
}
}
Nhưng nó không đủ để bảo vệ anh hùng, Thật vậy !!! Đây là điều tốt nhất chúng ta có thể / nên làm để giúp anh hùng của chúng ta
class Foo {
// Pay attention to volatile
private static volatile Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
if (INSTANCE == null) { // Check 1
synchronized (Foo.class) {
if (INSTANCE == null) { // Check 2
INSTANCE = new Foo();
}
}
}
return INSTANCE;
}
}
Đây được gọi là "Thành ngữ khóa kiểm tra hai lần". Thật dễ dàng để quên đi tuyên bố dễ bay hơi và khó hiểu tại sao nó lại cần thiết.
Để biết chi tiết: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Bây giờ chúng tôi chắc chắn về chủ đề ác nhưng những gì về tuần tự độc ác? Chúng ta phải đảm bảo ngay cả khi khử nối tiếp không có đối tượng mới nào được tạo
class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static volatile Foo INSTANCE = null;
// Rest of the things are same as above
// No more fear of serialization
@SuppressWarnings("unused")
private Object readResolve() {
return INSTANCE;
}
}
Phương thức readResolve()sẽ đảm bảo cá thể duy nhất sẽ được trả về, ngay cả khi đối tượng được tuần tự hóa trong lần chạy trước của chương trình của chúng tôi.
Cuối cùng, chúng tôi đã thêm đủ bảo vệ chống lại các luồng và tuần tự hóa nhưng mã của chúng tôi trông cồng kềnh và xấu xí. Hãy cho anh hùng của chúng tôi làm cho hơn
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
// Wrapped in a inner static class so that loaded only when required
private static class FooLoader {
// And no more fear of threads
private static final Foo INSTANCE = new Foo();
}
// TODO add private shouting construcor
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
// Damn you serialization
@SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
Vâng, đây là anh hùng rất giống nhau của chúng tôi :)
Vì dòng private static final Foo INSTANCE = new Foo();chỉ được thực hiện khi lớpFooLoader thực sự được sử dụng, điều này quan tâm đến việc khởi tạo lười biếng,
và nó được đảm bảo là chủ đề an toàn.
Và chúng tôi đã đi rất xa, đây là cách tốt nhất để đạt được mọi thứ chúng tôi đã làm là cách tốt nhất có thể
public enum Foo {
INSTANCE;
}
Mà nội bộ sẽ được đối xử như thế nào
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
Đó là nó! Không còn sợ nối tiếp, chủ đề và mã xấu xí. Ngoài ra singleton ENUMS được khởi tạo một cách lười biếng .
Cách tiếp cận này có chức năng tương đương với cách tiếp cận lĩnh vực công cộng, ngoại trừ nó ngắn gọn hơn, cung cấp máy móc tuần tự hóa miễn phí và cung cấp bảo đảm bằng sắt chống lại nhiều lần khởi tạo, ngay cả khi đối mặt với các cuộc tấn công tuần tự hoặc phản xạ tinh vi. Trong khi phương pháp này vẫn chưa được áp dụng rộng rãi, một loại enum đơn yếu tố là cách tốt nhất để thực hiện một singleton.
-Joshua Bloch trong "Java hiệu quả"
Bây giờ bạn có thể đã nhận ra lý do tại sao ENUMS được coi là cách tốt nhất để triển khai Singleton và cảm ơn vì sự kiên nhẫn của bạn :)
Đã cập nhật nó trên blog của tôi .