Рефакторинг безопасности потоков

Я пытаюсь сделать приложение Java поточно-ориентированным. К сожалению, он изначально был разработан для однопользовательского режима, и все ключевые классы созданы как одиночные. Что еще хуже, существует множество интерфейсов, работающих как контейнеры констант, и многочисленные статические поля.
Что в этом случае можно считать хорошей практикой?

  • Есть одна точка входа, поэтому я мог бы синхронизировать ее и просто использовать пул (вроде как), но если вызовы занимают в среднем больше минуты, всем остальным потокам в очереди придется долго ждать ...
  • Поскольку покрытие тестового кода не совсем оптимально, и я не могу быть уверен, что что-то упустил, некоторые подсказки о плохих шаблонах реализации (аналогичные тем, которые указаны выше) в этой области, были бы полезны.
  • Я знаю, что лучше всего было бы переписать всю структуру, но это не вариант.

java thread-safety refactoring
person user160048    schedule 20.08.2009    source источник

Ответы (6)


arrow_upward
0
arrow_downward

@coldphusion, вам придется читать / анализировать код. Использование автоматизированного инструмента, если такой инструмент существует, было бы похоже на выстрел себе в ногу.

Кроме того, не все должно быть потокобезопасным. Если к объекту никогда нельзя будет получить доступ из нескольких потоков, нет необходимости делать его потокобезопасным. Если объект неизменен, значит, он уже потокобезопасен.

Будьте готовы сказать своему боссу: «Это не займет несколько часов или день, даже если вы это знаете, поэтому перестаньте спрашивать».

Я рекомендую прочитать Java Concurrency In Practice.

person Community    schedule 20.08.2009
comment
Как я уже сказал, я ищу рутину, чтобы делать это вручную, а не инструмент :) В таких ситуациях всегда сложно найти с чего начать. Спасибо за книжный совет - посмотрю. - person user160048; 21.08.2009

arrow_upward
3
arrow_downward

Не похоже, что для этого есть быстрое решение. Вероятно, вам следует начать с рефакторинга существующего кода, чтобы использовать хорошие шаблоны проектирования, с прицелом на его многопоточность в будущем. Реализуйте многопоточность на более позднем этапе, после того, как вы очистите его.

person Jonathan    schedule 20.08.2009

arrow_upward
0
arrow_downward

Как упоминает Джонатан, это не похоже на быстрое решение.

Вы можете рассмотреть возможность использования ThreadLocal, чтобы предоставить выделенный синглтон для каждого потока. Очевидно, что это может быть, а может и не быть возможным, в зависимости от состояния, хранящегося в синглтонах, от того, нужно ли им делиться / поддерживать и т. Д.

person Adamski    schedule 20.08.2009
comment
Я не ищу в Eclipse волшебную функцию рефакторинга :) Меня интересуют общие шаблоны небезопасности потоков и правильный способ избавиться от них. В частности, если есть процедура проверки безопасности потоков. К этому моменту я могу написать только простую многопоточную тестовую программу запуска и ждать, пока какой-нибудь тест не сработает, что не гарантирует хороших результатов. - person user160048; 20.08.2009

arrow_upward
0
arrow_downward

Я добавлю к совету @ nevermind, так как он / она высказал несколько очень практических соображений.

Будьте практичны в том, что вам нужно изменить, чтобы выполнить свою задачу, поскольку волшебного пути нет. Ваш существующий код, хорошо спроектированный или нет, может нуждаться только в небольших изменениях в зависимости от того, как он используется. Конечно, это также означает, что может потребоваться полная переработка.

Здесь никто не может узнать (если только они не написали исходный код ;-)

Например, если вам нужно сделать доступ только к одному объекту (одноэлементному или нет) потокобезопасным, это довольно легко сделать, возможно, без какого-либо воздействия кодирования на вызывающего объекта такого объекта.

С другой стороны, если вам нужно изменить несколько объектов одновременно, чтобы сохранить целостность ваших данных / состояния, ваши усилия будут значительно труднее.

person Robin    schedule 20.08.2009

arrow_upward
0
arrow_downward

Синглтоны - это неплохо, и они не идут вразрез с безопасностью потоков, если они не хранят никакого состояния. Достаточно взглянуть на любое приложение J2EE; много синглтонов без состояния (только ссылки на другие синглтоны без состояния). Все состояние хранится в сессиях; вы могли бы имитировать это, но, как говорили другие, нет способа автоматически преобразовать ваше приложение; вам нужно будет провести хороший анализ, чтобы определить, как вы будете его реорганизовать, чтобы отделить все bean-компоненты без сохранения состояния от bean-компонентов с сохранением состояния, возможно, инкапсулировать состояние в некоторые объекты значений и т. д.

person Chochos    schedule 20.08.2009

arrow_upward
0
arrow_downward

Если кому-то эта тема тоже интересна - я нашел довольно подробный учебник на тему «что (не) делать» - с типичными ошибками и передовым опытом.
К сожалению, это доступно только в немецком банкомате: |

person user160048    schedule 21.08.2009