Статический метод, новый вопрос производительности потока

Question

У меня просто два вопроса о двух методах, используемых во многих контроллерах / сервлетах в моем приложении:

1 - в чем разница между вызовом статического метода в классе util или нестатического метода (например, методов, работающих с датами, т.е. получение текущего времени, преобразование между часовыми поясами), что лучше? 2 - в чем разница между вызовом метода (содержащего слишком много логики, например, отправкой электронных писем) в контроллере напрямую или выполнением этого метода в другом потоке?

Answer 1

1)

• У классов Utils обычно нет состояний, связанных с ними. У них просто есть поведение. Следовательно, на самом деле нет особого смысла создавать их «экземпляры».
• Несмотря на то, что компилятор никогда не будет жаловаться, создание экземпляра класса Util будет вводить в заблуждение.
• Классы использования Stateless Utils полностью поточнобезопасны. Методы класса, статические или нет, копируются в каждый кадр стека потоков и не создают помех друг другу. Классы Java Utils являются отличными примерами этого.

2)

• Если ваш метод занимает много времени, имеет смысл сделать его вызов асинхронным.

Answer 2

Существуют преимущества и недостатки использования статических методов:

Преимущества:

1. Вам не нужно создавать экземпляр объекта для их использования.
2. Статическийпеременные, определенные в классе, остаются неизменными между вызовами.

Недостатки:

1. Вы можете получить доступ только к статическим переменным и статическим методам, не создавая экземпляр объекта для их вызова.on.
2. Не является поточно-ориентированным по своей природе ... Вы должны синхронизировать метод или часть кода, если не хотите, чтобы другие потоки меняли переменные на вас.

По моему личному опыту, статические методы отлично подходят для вещей, которые не требуют, чтобы вы поддерживали состояние между вызовами.Как форматирование дат.

Сказав это, операции с временем довольно просты.Получить текущее время так же просто, как:

Date currentDate = new Date();

или

Calendar currentCal = Calendar.getInstance();

Календарь также можно использовать для roll Calendar.HOUR_OF_DAY (и Calendar.MINUTE если необходимо) если вы знаете разницу между часовыми поясами.

Answer 3

# 1 В других ответах, кажется, был получен хороший ответ.

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

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

Answer 4

1: Таким образом, ключевое слово static говорит только о доступности метода. Если метод static, он может быть доступен без создания объекта. Поэтому не имеет смысла спрашивать, что лучше: статическое или нестатическое.

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

Обратите внимание, что все это сказано в предположении, что программист знает, как выполнить правильную многопоточность ... если многопоточность не выполнена правильно, то может быть множество проблем: взаимоблокировки, недопустимые состояния объекта, снижение производительности и т. д.