Объем статических переменных класса в Java
По умолчанию они связываются с Ctrl + Numpad_Minus и Ctrl + Numpad_Plus , но можно снова переплести их.
4 ответа
Вероятная причина вашего ConcurrentModificationException заключается в том, что вы повторяете значения / записи объекта Properties в одном потоке, в то время как другой изменяет его в в то же время. Вы не можете этого сделать.
Не могли бы вы подробнее рассказать о механизме блокировки, который вы здесь упомянули:
Я использую статическую логическую переменную для «блокировки» объекта свойств, когда мой класс обновляет его, но это не сохраняет исключение из возникновения.
?
Потому что это не звучит так, как будто вы используете встроенные методы блокировки и синхронизации в Java.
Что-то вроде этого должно помешать потокам читать объект Properties, пока другой поток обновляет его:
static Object lockObject = new Object();
...
synchronized(lockObject) {
// access the Properties object
}
Обратите внимание, что вам нужно будет делать это каждый раз, когда вы обращаетесь к объекту Properties,
Вы можете обнаружить, что объем такой статической переменной ограничен одним для каждого ClassLoader, который загрузил ваш класс. Я не уверен, как Tomcat упорядочивает свои загрузчики классов, поэтому трудно сказать, какой размер области видимости будет в этой среде.
Статика «не является общей для всех экземпляров класса» - они не связаны с экземплярами; они принадлежат к самому типу . В частности, статические переменные вполне могут использоваться без создания каких-либо экземпляров.
Это дает ключ к пониманию объема статики: они ограничены объектом Class , представляющим содержащий класс, который, в свою очередь, находится в области видимости загрузчика ClassLoader , который его загрузил.
В зависимости от того, где размещена библиотека, статическая переменная может относиться к JVM или веб-приложению - или, возможно, что-то в между ними, если Tomcat поддерживает множественный хостинг (не могу вспомнить).
Посмотрите в документации Tomcat, как расположены библиотеки и как они соотносятся с загрузчиками классов. Например, здесь ' s практическое руководство Tomcat 6.0 ClassLoader и эквивалент 5.5 .
Как работает ваша логическая «блокировка»? Вам действительно следует использовать правильную блокировку ( synchronized ), чтобы гарантировать, что каждое использование объекта свойств (как чтение, так и запись, включая блокировку в течение всего периода, в течение которого вы выполняете итерацию) заблокировано соответствующим образом.
Вместо изменения "живого" объекта Properties , рассматривали ли вы его как неизменяемый - поэтому, когда вы хотите обновить свойства, вы берете копию, изменяете ее, а затем делаете копию " живая »версия? Вам все равно придется не допускать одновременного внесения изменений двумя разными потоками (иначе вы потеряете некоторые), но это, вероятно, сделает сторону чтения намного проще и эффективнее.
Может быть, проблема в загрузчике классов, когда jar-файл, содержащий ваш класс, дублируется в каждой WEB-INF / lib ваших различных приложений? Если так, я бы попытался добавить эту банку в библиотеки Tomcat, а не в приложение.