Безопасность типов java: не параметризованный эффект общего типа на производительность - PullRequest
Новая
       53

Безопасность типов java: не параметризованный эффект общего типа на производительность

0 голосов
/ 27 июля 2011

я хочу знать, есть ли риск для безопасности или есть и другие преимущества я получаю при параметризации списка.

я получаю это предупреждение

Список является необработанным типом. Ссылки на универсальный тип Список должен быть параметризованных

при объявлении списка, например 

List myList;

и если я перехожу на это, то предупреждения нет 

List<?> myList;

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

редактировать : и если я перейду на конкретный тип, это повлияет на производительность? 

List<String> myList;

Ответы [ 5 ]

4 голосов
/ 27 июля 2011

если я не параметризирую список, будет ли код работать медленнее?

нет

нет

я имею в виду, нужно ли будет больше проверять во время выполнения?

нет

нет

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

2 голосов
/ 27 июля 2011

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

Редактировать

Определенные типы также не будут влиять на производительность так или иначе.Вкратце: информация об универсальном типе доступна только компилятору (javac), который не выполняет никакой оптимизации (за исключением некоторых действительно тривиальных и несущественных здесь вещей).Оптимизация выполняется JVM и JIT-компилятором, которые не имеют доступа к информации об универсальных типах - следовательно, нет разницы в производительности.

1 голос
/ 27 июля 2011
  1. Проверка времени компиляции уменьшит вероятность ошибок во время выполнения.
  2. При использовании итератора уменьшит количество строк кода, поскольку вам не требуется явно приводить.
  3. Это хорошая практика.
  4. Эта практика улучшит читабельность кода.
  5. Также я считаю, что вам следует адаптироваться к более новым версиям (дженерики добавлены в jdk 1.5)
1 голос
/ 27 июля 2011

Это определенно относится к области преждевременной оптимизации.Изменения, внесенные компилятором при добавлении параметров типа в коллекции в сгенерированный байт-код, являются просто приведениями.Когда вы пишете: 

List<String> values = new ArrayList<String>();
values.add("One");
values.add("Two");

String value = values.get(0); // syntactic sugar

Компилятор генерирует для последней строки байткод, соответствующий кодированию, равный 

String value = (String) values.get(0);

Таким образом, скрытая стоимость - это стоимость приведения.Как указывает ответ Тома Хоутина на «Вводит ли Java-кастинг накладные расходы?» :

Что такого рода вещи в основном не имеют отношения к производительности.

, с которым я склонен согласиться - не беспокойтесь о снижении производительности при использовании дженериков.

1 голос
/ 27 июля 2011

Компилятор не может вам помочь, если вы не параметризовали свои экземпляры.

Использование List<?> во избежание проверок времени компиляции не рекомендуется, если вы действительно не знаете тип во время компиляции (бывают случаи, когда это так, поэтому я не говорю, что никогда не используйте его). 1004 *

...