'Опытный' шаблон Java - новый по сравнению с клоном по сравнению с class.newInstance
В моем проекте существуют некоторые 'Опытные' фабрики, которые создают экземпляры путем клонирования заключительного частного экземпляра.
Автор тех фабрик говорит, что этот шаблон обеспечивает лучшую производительность, чем вызов 'нового' оператора.
Используя Google для получения некоторых подсказок, о которых, я не сделал, нашел что-либо релевантным. Вот маленькая выборка, найденная в javdoc из неизвестного проекта
К сожалению, клон () скорее медленнее, чем вызов нового. Однако это намного быстрее, чем вызов java.lang. Class.newInstance (), и несколько быстрее, чем прокрутка нашего собственного метода "клона".
Для меня это похоже на старую лучшую практику времени java 1.1. Кто-то знает больше об этом? Действительно ли это - хорошая практика для использования этого с 'современным' jvm?
4 ответа
Безусловно, этот вид практики полностью устарел. С тех пор виртуальная машина Java значительно улучшилась. Создание объекта крайне дешево. Другая связанная с этим практика, объединение объектов в пул, также устарела, потому что затраты на создание и очистку объектов теперь намного более эффективны. В некоторых случаях это может быть полезно ( Джон Скит приводит здесь несколько хороших примеров ), но никоим образом не должен быть частью базовой библиотеки фреймворка, такой как эта.
Я бы посоветовал найти несколько новых библиотек и / или новый проект для работы; -)
Прочтите эту статью класса Java Urban Performance Legends , чтобы получить больше информации.
Как говорили другие, это устаревшая практика. Это устаревший шаблон, который, к сожалению, с новыми JVM приведет к увеличению кода без повышения производительности.
Хотелось бы, чтобы у меня еще был код, чтобы я мог поделиться им, но некоторое время назад я провел простой тест производительности этого шаблона по сравнению с использованием оператора 'new' и обнаружил, что использование оператора 'new' в худшем случае так же быстро, как этот шаблон, и в лучшем случае быстрее и эффективнее. Могут быть некоторые крайние случаи, которые мой тест не охватил, где это все еще может быть допустимым подходом, но в целом я бы сказал, что избегайте этого шаблона.
Еще одно замечание: я бы посоветовал вам не слишком беспокоиться об этом, если он присутствует в существующей кодовой базе. Но также я бы не стал писать новый код, чтобы расширить этот шаблон для большего количества частей вашего проекта, если только это не повлияет на ясность и согласованность вашей базы кода - в этот момент вы должны оценить, будет ли он разумным в долго нужно реорганизовать этот код из вашего проекта. Под «умным» я подразумеваю, что рефакторинг этого кода из вашего проекта сэкономит время в будущем на разработке и отладке> количество времени, необходимое для этого рефакторинга.
Ну и дела. Это одна из худших идей, которые я когда-либо слышал.
Не делай странных вещей. Даже если вы измерили и заметили некоторое очевидное улучшение (ну, в данном случае вероятность этого равна нулю), подумайте еще долго, прежде чем делать это ... Кто знает, это будет исправлено в следующей JVM. Тогда у вас останется какой-то странный фрагмент кода, который работает хуже, его трудно читать, и из-за этого есть некоторые ошибки.
Я имею в виду, что люди, разрабатывающие JVM, не такие идиоты! Используйте новый !
Я думаю, вам следует избавиться от этого странного фрагмента кода.
Нет.
О, мне нужно больше символов для ответа. Итак, позвольте мне расширить и сказать, что такая микрооптимизация неуместна, если нет проблемы, а если она есть, вы должны быть в состоянии измерить, улучшит ли она ситуацию.