Потокобезопасный рефакторинг

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Никто здесь не может знать (если они не написали оригинальный код; -)

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

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

Answer 5

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

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

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

Я рекомендую прочитать Параллелизм Java на практике .

Answer 6

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

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