#java #interface #jvm #static-members
#java #интерфейс #jvm #статические члены
Вопрос:
Согласно концепции о статических членах, они создаются / загружаются в память при первом вызове его класса. И они являются общими для всех экземпляров этого класса. Означает, что они не создаются заново или повторно инициализируются и т.д. Кроме того, к ним можно получить доступ только по имени класса. Нет необходимости создавать объект для этого класса только для доступа к ним.
Теперь мои вопросы;
- Будут ли статические элементы когда-либо находиться в памяти до запуска приложения? даже если все экземпляры этого класса были собраны GC (сборщиком мусора).
- Для большого проекта, где 8-10 команд работают вместе, они не заботятся о кодировании другой команды. Они могут создавать статические элементы в соответствии со своими потребностями. Если все элементы кэшируются в памяти, не приведет ли это к накладным расходам на JVM?
- По умолчанию все элементы интерфейсов являются СТАТИЧЕСКИМИ, и использование интерфейсов полезно во многих случаях. Но если я буду помнить о своих вышеуказанных вопросах, должен ли я по-прежнему использовать интерфейсы?
Комментарии:
1.
Premature optimization is the root of all evil (or at least most of it) in programming.— Дональд Кнут2. Это случай отсутствия леса для деревьев. За всю мою профессиональную карьеру я всегда сталкивался с утечками памяти, возникающими из-за утечки нестатических элементов. Хотя эти опасения, указанные в вопросе, могут быть обоснованными, вряд ли они являются причиной нагрузки на JVM.
3. В продолжение, я предполагаю, что, когда все сказано и сделано, вы захотите потратить больше времени и усилий на читаемость кода, повторное использование, высокую связность и низкое сцепление, чем на беспокойство о мелочах, связанных с переменной площадью.
4. Если вы обеспокоены тем, что ваш большой проект столкнется с проблемами из-за слишком большого количества статических переменных, появляющихся в коде, попробуйте поощрять модульное тестирование. Статические переменные затрудняют модульное тестирование, поэтому разработчики, надеюсь, обратятся к разработке кода без них, если это действительно не понадобится.
5. 1 за это очень хорошее предложение.
Ответ №1:
1) Статические члены являются мусором, собираемым только тогда, когда класс, который их определяет, сам собран; это, в свою очередь, может произойти, только если собран определяющий ClassLoader. Это распространено в контейнерах веб-приложений и архитектурах плагинов.
2) Да, определение большого объема статических данных может быть плохой идеей. Но это похоже на множество других вещей: это хорошо, если вам это нужно, и плохо, если вы злоупотребляете этим. Просто используйте здравый смысл.
3) Опять же, интерфейс, который определяет массив из тысячи строк, был бы плохой идеей, но, конечно, обычно люди этого не делают. Просто используйте здравый смысл. Нет причин (связанных с памятью) избегать статических переменных вообще.
Комментарии:
1. Эй, Эрнест, ты владелец ранчо? Просто любопытно, являетесь ли вы тем самым…. Мне понравились ваши сообщения там, и вы много раз помогали мне.
2. Важно сказать: 1) произойдет не в течение срока службы приложения, а только тогда, когда корпоративное приложение будет остановлено и, в свою очередь, повторно развернуто на сервере приложений.
3. @Adeel Ansari: да, это я. Я тоже узнал ваше имя. Приятно видеть вас здесь!
4. @Ernest: Приятно слышать, что вы тоже узнали мое имя. Кстати, 10 тысяч за 2 месяца, ВАУ! Продолжайте в том же духе…
5. @articlestack: не знаю, как сказать это мягко, так что: я прав, а он ошибается 🙂 Уникальный класс в Java на самом деле определяется не просто именем класса, а парой [class, classloader]. Один и тот же файл класса может быть загружен более чем в один classloader. Следовательно, «синглтон» может фактически существовать несколько раз. Одна из этих копий может быть собрана как мусор, если никакой код никогда не сможет получить к ней доступ: т. Е. Если ни один стек потока не содержит ссылки на какие-либо объекты, созданные из классов, загруженных этим classloader. В этом случае, поскольку к этому одноэлементному экземпляру никогда нельзя получить доступ с помощью запущенного кода, его можно отбросить.
Ответ №2:
-
ДА. Никакой GC никогда не будет очищать статические переменные. Это важно, потому что в противном случае нельзя было бы полагаться на значения, хранящиеся в статических переменных. Шаблоны проектирования, такие как «Singleton», полагаются на статические переменные.
-
Статические переменные занимают столько памяти, сколько одно и то же значение, хранящееся в переменной экземпляра, поэтому, пока значение, хранящееся в переменной, действительно необходимо для сокращения, статические переменные не требуют особых затрат на хранение. Но побочные эффекты, возникающие при использовании статических переменных, когда дело доходит до потокобезопасности и т.д., Необходимо учитывать больше, чем проблемы с памятью.
-
ДА. Но интерфейсы существуют для описания контракта между поставщиком и пользователем функциональности, а не для хранения каких-либо данных.
Комментарии:
1. 1) Интерфейсы также хранят изменяемые данные «final static public», 2) Пожалуйста, сравните вашу точку зрения (1) с точкой @Ernest(1)
Ответ №3:
-
Нет, они собираются вместе с классом.
-
Накладные расходы по сравнению с чем? Какова альтернатива?
-
Да, но никто не говорил, что вы должны заполнять их статическими элементами.
Комментарии:
1. Накладные расходы ни с чем не сравнимы. Если что-то не дает хороших результатов, люди изобретают новые вещи. они не прекращаются, поскольку альтернативы не существует
2. @articlestack: «накладные расходы по сравнению с ничем» бессмысленны. Переменные либо требуются, либо нет. Если они не нужны, не создавайте их. Я не знаю, что означают ваши 2-е и 3-е предложения по этому вопросу.
3. Я думаю, что чистый абстрактный класс мог бы быть альтернативой интерфейса. (Я знаю его недостаток, поскольку класс может наследовать только один класс, но реализовывать множество интерфейсов.)
4. @articlestack конечно, это альтернатива, но накладные расходы идентичны.