Я новичок в Java EE. Интересно, существуют ли некоторые распространенные случаи тупика в прикладном уровне Java EE, возникающие в результате использования примитива синхронизации Java с синхронизацией. Если да, может помочь привести пример?Заблокировать тупик в приложении Java EE
ответ
public void myMethod1() throws Exception {
synchronized (MyClass.class) {
Thread.sleep(10*1000);
synchronized (MyClass2.class) {
}
}
}
public void myMethod2() throws Exception {
synchronized (MyClass2.class) {
Thread.sleep(10*1000);
synchronized (MyClass1.class) {
}
}
}
Вызов myMethod1
из одного потока и myMethod2
из другого потока, и вы получите в тупик.
Из спецификации EJB 3.1, глава 21.2.2. Программирование Ограничение:
Предприятия компоненты не должны использовать нить примитивов синхронизации для выполнения Синхронизировать нескольких экземпляров, за исключением, если это Singleton сессионного компонент с бобовым управляемым параллелизмом.
И рассуждения интересны:
Синхронизация не будет работать, если экземпляры в EJB контейнер распределенного предприятия бина на нескольких виртуальных машинах.
Любая идея, как это делается в EJB 3.0? У него еще нет singelton, поэтому примитивы синхронизации кажутся единственным способом обойти его ... – mglauche
Прекрасный пример! Это распространено в сервлете или EJB? Или это просто происходит в приложениях J2SE? –
Это может произойти в любом случае. Здесь следует отметить, что мы берем замки в обратном порядке. Когда блокировки берутся, мы всегда должны принимать блокировки в заранее определенном/одинаковом порядке, чтобы взаимоблокировки не происходили. –