Вопросы производительности при использовании @SuppressWarnings («не проверено»)

Question

Надеюсь, у вас все хорошо.

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

Сценарий 1:

public List<BusinessObject> retrieveInformation(Long id){
    List<? extends Object> info = persistenceService.get("namedQuery", params, values);
    //... cast the contents one by one to List<BusinessObject> and return
}

Сценарий 2:

public List<BusinessObject> retrieveInformation(Long id){
    List<?> info = persistenceService.get("namedQuery", params, values);
    //... cast the contents one by one to List<BusinessObject> and return
}

Сценарий 3:

public List<BusinessObject> retrieveInformation(Long id){
    List<BusinessObject> info = (List<BusinessObject>)persistenceService.get("namedQuery", params, values);
    //... return the List<BusinessObject>
}

Сценарий 4:

@SuppressWarnings("unchecked") 
public List<BusinessObject> retrieveInformation(Long id){
    List<BusinessObject> info = persistenceService.get("namedQuery", params, values);
    //... return the List<BusinessObject>
}

Конечно, есть намного больше способов сделать это, но моя забота - способ сделать этот процесс с наилучшей производительностью.Таким образом, мы должны принять во внимание, что при получении информации у нас может быть ошибка в запросе, и будет исключение;Кроме того, если такой ошибки нет, мы уже знаем тип объектов, которые будут извлечены.

Итак, обдумывая это с точки зрения крупного бизнес-проекта со всеми его компонентами вПоместите, скажем, слой гибернации, DAO и DTO, не могли бы вы помочь мне определить:

1. Один вариант с лучшими характеристиками производительности.
2. Если аннотация @SuppressWarnings ("unchecked")имеет соображения производительности.
3. Если избавление от @SuppressWarnings ("unchecked") является хорошей практикой в ​​этой области.

Хорошего дня.

Answer 1

@ SuppressWarnings влияет только на компилятор и только для того, чтобы компилятор не отображал предупреждения.

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

Сценарий 3 - это ваша лучшая ставка, при условии, что вы получаете список с вашего звонка с точки зрения качества кода.Все четыре сценария будут давать одинаковый результат.

Answer 2

Насколько я знаю, @SuppressWarnings аннотации не влияют на производительность.Они существенно не изменяют генерируемые байт-коды.

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

Кроме того, если (гипотетически) компилятор действительно вставляет некоторые байт-коды приведения типов, которые не являются строго необходимыми, они должны быть оптимизированы компилятором JIT.

---

Однако лучше написать свой код, чтобы вам не нужно было использовать @SuppressWarnings аннотации.Проблема в том, что аннотации могут скрывать логические ошибки в вашем коде;то есть предупреждения могут быть реальными.Если не обнаружено тщательным интеграционным тестированием модулей и , это может привести к непредвиденным ошибкам во время выполнения.

---

^{1 - Если компилятор этого не сделал, то при загрузке JVM байт-коды не пройдут проверку.}