Если все классы содержат множество полезных переменных класса, повлияет ли это на производительность?

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

Несмотря на то, что переменные класса состоят в основном из примитивных переменных, таких как булевы, целые числа, двойники и т. д., Мне до сих пор это непросто чувствую, что некоторые из моих классов с большим количеством переменных класса могут оказывать влияние на производительность, как бы незначительны они ни были.

Но будучи рациональным, насколько это возможно, если я рассматриваю неограниченный размер ОЗУ и неограниченные переменные класса Java, класс Java может быть бесконечно большим блоком памяти в ОЗУ, в котором первая часть блока содержит разделы переменных класса, а остальная часть блока содержит адреса методов класса в пределах класса Java. При таком объеме оперативной памяти производительность для него очень нетривиальна.

Но это выше не делает мои чувства легче, чем сказано. Если бы мы рассматривали ограниченную оперативную память, но неограниченные переменные класса Java, каков был бы результат? Что на самом деле произойдет в среде, где важна производительность?

И, вероятно, может быть упомянуто заранее, я не знаю, считается ли наличие большого количества переменных класса плохой практикой Java, когда все они важны, и все классы были рефакторинг.

Заранее благодарю.

7 7
performance

7 ответов:

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

На ремонтопригодность и читаемость влияет количество полей, которые имеет объект. хотя. 40-50 полей-это довольно много полей, и, вероятно, это признак того, что ваши классы слишком много делают сами по себе и имеют слишком много обязанностей. Рефакторинг их на множество более мелких подклассов и использование композиции, вероятно, было бы хорошей идеей.

19

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

С точки зрения производительности, если вы Очень часто нуждаетесь во всех этих свойствах, то вы будете сохранять некоторую память, так как каждый объект также имеет заголовок. Поэтому вместо того, чтобы иметь 5-10 классов, вы помещаете все в один и сохраняете несколько байт.

В зависимости от того, какой сборщик мусора вы используете, наличие больших объектов может быть больше дорого выделять (это верно для сборщика мусора CMS, но не для параллельного). Больше работы GC = меньше времени для запуска вашего приложения.

Если вы не пишете приложение с высоким трафиком и низкой задержкой, преимущества меньшего количества классов (и использования меньшего объема памяти) будут полностью подавлены дополнительными усилиями, необходимыми для обслуживания.

5

Самая большая проблема, которую я вижу в классе с большим количеством переменных, - это потокобезопасность - в таком случае будет очень трудно рассуждать об инвариантах. Кроме того, чтение / ведение такого класса будет очень трудно.

Конечно, если вы сделаете как можно больше полей неизменяемыми, это будет намного лучше.

Я стараюсь идти с : чем меньше, тем лучше, легче поддерживать.

3

Основной принцип, которому нас всегда учат, состоит в том, чтобы поддерживать высокую сплоченность (один класс сосредотачивается на одной задаче) и низкую связь (меньшая взаимозависимость между классами, чтобы изменения в одном не влияли на другие).

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

Например, если у меня есть требование, когда приложение предлагает курс студенту, а алгоритм требует 50 входов (оценки, хобби и т. д.), не будет иметь значения, доступны ли эти данные в одном классе или нескольких, так как вся информация должна быть загружена в оперативную память для более быстрого выполнения.

Я снова скажу, позаботьтесь о своем дизайне, это и вредно держать ненужные переменные в классе (так как это загрузит ненужную информацию в оперативную память) или разбить на более классы, чем требуется (больше ссылок и, следовательно, движение указателя)

1

1. я всегда использую это как правило. Класс должен иметь только одну причину для изменения, поэтому он должен делать только одну вещь.

2. Имея это в виду, я беру те переменные, которые необходимы для определения атрибутов этого класса.

3. я удостоверяюсь, что мой класс следует Cohesive principle, где методы внутри класса отражают имя класса.

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

1

Иногда переменные класса используются в качестве статических конечных констант для хранения некоторых строк по умолчанию, таких как название продукта, версия, версия ОС и т. д. Или даже хранить специфические настройки продукта, такие как размер шрифта, тип и т. д. Эти статические переменные могут храниться на уровне класса.

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

0

Две вещи, которые я хотел бы упомянуть : 1. Все переменные экземпляра хранятся в области кучи оперативной памяти.. 2. Все статические переменные хранятся в области без кучи (область метода, чтобы быть конкретным).

Каким бы ни был тип переменной(экземпляр или статическая), в конечном счете все они находятся в оперативной памяти.

Теперь перейдем к вашему вопросу. Что касается переменной экземпляра, встроенный сборщик мусора java будет работать, в большинстве случаев хорошо и действительно эффективно, чтобы продолжать освобождать память. Однако статические переменные мусор не собирают.

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

0