Удостоверьтесь, что Java синхронизировался, блокировки взяты в порядке?
Я в настоящее время "вручную" делаю его через Задачу должностного лица перед сборкой, с помощью моего инструмент cmdnetsvnrev , но если бы кто-то знает лучший ccnet-интегрированный способ сделать его, я был бы рад услышать:-)
6 ответов
Нет, synchronized предоставит доступ в любом порядке (зависит от реализации JVM). В некоторых сценариях это может даже привести к тому, что потоки будут голодать.
Вы можете обеспечить порядок, используя ReentrantLock (начиная с Java 5.0) с параметром fair = true . ( Lock lock = new ReentrantLock (true); )
c) есть ли лучший способ сериализации запросов?
Вы случайно не используете список в качестве очереди, т. Е. Выглядит ли шаблон использования примерно так?
while (some condition) {
synchronized(theList){
anItem = get and remove an element from theList
}
do some work with anItem
}
Если это так, вы можете взглянуть на интерфейс BlockingQueue вместо того, чтобы использовать свои собственные схемы блокировки. Реализации (например, ArrayBlockingQueue ) имеют настройки для справедливости и многое другое.
Я всегда оставляю синхронизацию с сервером приложения или движком, если не определяю собственную интенсивность
Нет, вы не можете быть уверены, что два вызова синхронизированного метода будут происходить по порядку. Порядок не указан и зависит от реализации.
Это определено в разделе 17.1 Locks JLS. Обратите внимание, что это ничего не говорит о порядке, в котором потоки, ожидающие блокировки, должны получать доступ.
Вы не можете полагаться на порядок, в котором конкретный метод вызывается из каждого потока. Если это только два потока, может быть и да. Но представьте, что есть 3 потока и 1 поток уже получил доступ. Другие 2 потока, когда они попытаются получить доступ, будут ждать, и любой из них может получить доступ, и это не зависит от порядка, в котором они вызвали этот метод. Так что полагаться на заказ не рекомендуется.
Да.
Если доступ к списку осуществляется с помощью одного синхронизированного метода, параллельные запросы из нескольких потоков будут сериализованы.