- 1
- 2
- 3
- 4
- 5
- 6
public List<OrderEntity> getOrders() {
if (orders == null) {
orders = new ArrayList<OrderEntity>();
}
return orders;
}-
Java / Говнокод #7955
+148
Потокобезопасность? Не, не слышал.
Запостил:
roman-kashitsyn,
23 Сентября 2011
Follow us!
КЭП
КЭП №2
вы меня троллите?
короче, я это говнокодом совершенно не считаю. Может быть из контекста было бы понятно в чем проблема. (Автор несёт в треде что-то подозрительное)
Но если подходить ко всему с подходом не "потокобезопасно", то и i++ надо бы помещать под локи.
> то и i++ надо бы помещать под локи
не надо, поскольку это локальная переменная, которую два потока совместно использовать никогда не смогут.
кто сказал.
\\OLOLOLO
public void getOrders() { i++; }
поговнокодю ка я на шарпе
Тут всем понятно, что GetOrder говнокод. Но ничего не понятно из примера roman-kashitsyn'а.
но я бы писал так
foo.BeginInvoke(null, null);
foo.BeginInvoke(null, null);
Можно написать так (типо короче).
> проще априори считать, что все классы не рассчитаны на threadsafe
как правило, большинство кодеров вряд ли рассматривает этот вопрос, а проблемы начнутся, есть небезопасный использовать, полагая, что он безопасен - нежели наоборот...
Говнокодеров, которые даже не знали, что их взяли в проект с многопоточностью.
ArrayList тут как пример, что не потокобезопасные совершенно не говно.
Представим вам надо сделать логирование обращений к полю, или там бряк по обращению поставить.
На самом деле я всегда использую access=field, чтобы иметь возможность создавать immutable объекты.
Если это некий статический объект, содержащий всю конфигурацию и данные приложения, то что-то мне подсказывает, что там есть архитектурный говнокод. Если нужен кеш, то во всяких там Hibernate есть кеш. Есть кеши на уровне Application сервера. Причем все эти решения поддерживают репликацию кеша между несколькими нодами/системами. И никаких рисков внести потоко-небезопасный код нет.
Юзайте Spring MVC, он избавит вас от неверных архитектурных решений :)
сталкивался на практике с ситуацией, когда таких вот коллекций в объекте было штук 5 а то и больше, а объектов в памяти было 500к+. оверхед по памяти нехеровый выходит, если сразу инициализировать.
. Можно ещё попробовать прикрутить AtomicReference<List<OrderEntity>>, но тут возникают некоторые трудности, методов борьбы с которыми я не знаю.
В этих паттернах очень много построено на том, что поле является static.
Как подобный паттерн можно применить в случае обычного объекта?