final class Singleton {
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
Но товарищ Allen Holub заметил, что использование volatile модификатора может привести к проблемам производительности на мультипроцессорных системах.
Покритикуйте использование не блокирющего алгоритма взамен синхронизации, например:
final class NonBlockSingleton {
private static final AtomicReference<NonBlockSingleton> ref = new AtomicReference<NonBlockSingleton>();
public static NonBlockSingleton getInstance() {
if (ref.get() == null) {
NonBlockSingleton instance = null;
do {
instance = new NonBlockSingleton();
} while (ref.compareAndSet(null, instance));
}
return ref.get();
}
}
Здравствуйте, Alstresh, Вы писали:
A>Покритикуйте использование не блокирющего алгоритма взамен синхронизации, например:
Два параллельных потока у вас создают 2 экземпляра.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Alstresh, Вы писали:
A>>Покритикуйте использование не блокирющего алгоритма взамен синхронизации, например: B>Два параллельных потока у вас создают 2 экземпляра.
Да, там перемудрил, а если так:
final class NonBlockSingleton {
private static final AtomicReference<NonBlockSingleton> ref = new AtomicReference<NonBlockSingleton>();
public static NonBlockSingleton getInstance() {
if (ref.get() == null) {
ref.compareAndSet(null, new NonBlockSingleton());
}
return ref.get();
}
}
A>final class NonBlockSingleton {
A> private static final AtomicReference<NonBlockSingleton> ref = new AtomicReference<NonBlockSingleton>();
A> public static NonBlockSingleton getInstance() {
A> if (ref.get() == null) {
A> NonBlockSingleton instance = null;
A> do {
A> instance = new NonBlockSingleton();
A> } while (ref.compareAndSet(null, instance));
A> }
A> return ref.get();
A> }
A>}
A>
Мне кажется, что из N потоков прошедших проверку if (ref.get() == null), N-1 поток из do..while не выйдут никогда.
Здравствуйте, Alstresh, Вы писали:
A>Есть известная реализация синглтона A>Покритикуйте использование не блокирющего алгоритма взамен синхронизации, например:
Подобная оптимизиация, кроме всего прочего, ещё и лишена смысла. Подумайте логически, без кода, какого именно поведения вы хотите добиться. Что именно оптимизируется?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Alstresh, Вы писали:
A>>Есть известная реализация синглтона A>>Покритикуйте использование не блокирющего алгоритма взамен синхронизации, например: B>Подобная оптимизиация, кроме всего прочего, ещё и лишена смысла. Подумайте логически, без кода, какого именно поведения вы хотите добиться. Что именно оптимизируется?
А что здесь то же самое? Открываем javadoc
Atomically sets the value to the given updated value if the current value == the expected value.
boolean java.util.concurrent.atomic.AtomicReference.compareAndSet(NonBlockSingleton expect, NonBlockSingleton update)
Т.о если два потока одновременно попытаються создать инстанс, то создаст только один из них, а второй отвалиться по условию "current value == the expected value". Я хочу избавиться от блjкирующего алгоритма и volatile
A>Но товарищ Allen Holub заметил, что использование volatile модификатора может привести к проблемам производительности на мультипроцессорных системах. A>Покритикуйте использование не блокирющего алгоритма взамен синхронизации, например: A>
A>final class NonBlockSingleton {
A> private static final AtomicReference<NonBlockSingleton> ref = new AtomicReference<NonBlockSingleton>();
A> public static NonBlockSingleton getInstance() {
A> if (ref.get() == null) {
A> NonBlockSingleton instance = null;
A> do {
A> instance = new NonBlockSingleton();
A> } while (ref.compareAndSet(null, instance));
A> }
A> return ref.get();
A> }
A>}
A>
Че-то я не понял. Ты в исходники не смотрел?
java.util.concurrent.atomic.AtomicReference#value:
private volatile V value;
Думаю, что товарищ Allen Holub говорил о несколько ином контексте. Кстати, а можно ссылку на первоисточник?
Здравствуйте, PZI, Вы писали:
A>>Есть известная реализация синглтона PZI>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking?
Почему бы и нет?
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, PZI, Вы писали:
A>>>Есть известная реализация синглтона PZI>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking? SK>Почему бы и нет?
эм... ну скажем так, возможная выгода от его использования очень мала, в сравнении с другими варантами реализации синглетона.
Здравствуйте, PZI, Вы писали:
A>>>>Есть известная реализация синглтона PZI>>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking? SK>>Почему бы и нет? PZI>эм... ну скажем так, возможная выгода от его использования очень мала, в сравнении с другими варантами реализации синглетона.
А какими другими? Без контекста очень трудно
Здравствуйте, StanislavK, Вы писали:
PZI>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking? SK>Почему бы и нет?
Потому что ClassLoading в Java и так ленивый и потокобезопасный. В чем бенефит double check locking?
A>final class NonBlockSingleton {
A> private static final AtomicReference<NonBlockSingleton> ref = new AtomicReference<NonBlockSingleton>();
A> public static NonBlockSingleton getInstance() {
A> if (ref.get() == null) {
A> NonBlockSingleton instance = null;
A> do {
A> instance = new NonBlockSingleton();
A> } while (ref.compareAndSet(null, instance));
A> }
A> return ref.get();
A> }
A>}
A>
В AtomicReference тот же volatile и используется. Так что, учитывая что конструктор у тебя будет вызваться каждый раз, то непонятная какая тут оптимизация.
Избавиться от волатайл можно двумяя способами.
1. Можно его не висать если все поля в синглноне final. Тогда проблем с синглтоном не будет.
2. Использовать inner static holder.
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, PZI, Вы писали:
A>>>>>Есть известная реализация синглтона PZI>>>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking? SK>>>Почему бы и нет? PZI>>эм... ну скажем так, возможная выгода от его использования очень мала, в сравнении с другими варантами реализации синглетона. SK>А какими другими? Без контекста очень трудно
Ну хотя бы такое, если уж совсем приперло инициализацию по дерганью метода сделать.
Здравствуйте, PZI, Вы писали: PZI>Здравствуйте, StanislavK, Вы писали: SK>>Здравствуйте, PZI, Вы писали: PZI>>>>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking? SK>>>>Почему бы и нет? PZI>>>эм... ну скажем так, возможная выгода от его использования очень мала, в сравнении с другими варантами реализации синглетона. SK>>А какими другими? Без контекста очень трудно PZI>Ну хотя бы такое, если уж совсем приперло инициализацию по дерганью метода сделать.
Ах, вот почему…
Мне видится по крайней мере одно преимущество double check locking по сравнению с initialization on demand holder — меньше размер байткода на сотню-две байт. Для J2ME или апплетов играет.
Здравствуйте, gegMOPO4, Вы писали:
MOP>Мне видится по крайней мере одно преимущество double check locking по сравнению с initialization on demand holder — меньше размер байткода на сотню-две байт. Для J2ME или апплетов играет.
В J2ME и апплетах с многопоточностью попроще.
