У меня есть две строки, как показано ниже:Использует ли оператор присваивания память в Java?
"yes", "no".
Теперь я хотел бы сравнить эти строки двумя способами:
Непосредственно:
Пример: "yes".equals("no")
Назначая строки некоторой переменной: Пример:
String string1 = "yes";
String string2 ="no";
string1.equals(string2);
В этих двух случаях есть ли разница в памяти или производительности?
Существует очень незначительная разница (фактически это незначительно, мы говорим о микро-оптимизации здесь), так как строка должна храниться в локальной переменной, которая берет этот дополнительный бит памяти в стеке соответствующего метода. В то время как константы фактически хранятся в постоянном пуле и совместно используются. С вероятной оптимизацией JVM, основанной на количестве вызовов, это не изменит ситуацию.
Обратите внимание, что байт-код будет таким же, если переменные были final или эффективно final (присвоены только один раз), так как в этом случае они рассматриваются как константы.
* Обратите внимание: не было бы никакой разницы, если бы переменные были окончательными, и в этом случае они эффективно рассматриваются как константы. *> Также обратите внимание, что если переменные не переназначаются где-то в другом месте кода, компилятор распознает их как неявно «final» и сделать ту же оптимизацию, которая была бы выполнена, если бы ключевое слово «final» было явно использовано. – errantlinguist
Я не думаю, что здесь задействована куча. Это ссылки на строки в постоянном пуле. Контрольные переменные хранятся в стеке AFAIK. – Puce
В нашем коде, если мы выполняем это задание примерно 100 раз. Тогда он потребляет память и производительность? –
В зависимости от компилятора, возможно, это займет 2 дополнительных ссылки на объекты в стеке. Они достаточно малы, вы обычно можете игнорировать их, если вы не профилировали свое приложение, и вы заметили проблему там (очень маловероятно).
«да» .equals («нет»)
В реальном коде вряд ли когда-нибудь такая ситуация, как вы уже знаете, если 2 литералы являются одинаковыми или нет.
Компиляция этих фрагментов кода приведет к тому же байт-код. Следовательно, нет потребления памяти или разницы в производительности.
Оператор присваивания никогда не потребляет память (кроме случаев автообщения: Integer number = 42). Объявление локальной переменной может выделять память в стеке (если это необходимо), но вы должны предпочесть читаемость кода.
Для чисел, меньших некоторой константы (128?), Автобоксинг также не использует память. – Cephalopod
@Cephalopod Вы правы, для номеров в диапазоне [-128, 127] гарантируется JLS7 5.1.7 – fRoStBiT
Обратите внимание, что верхняя граница может быть изменена, поэтому я сомневаюсь, что она явно гарантирована. –
такая же производительность – Andrew
Трудно рассуждать о таких небольших фрагментах кода. Независимо от того, ссылаются ли переменные в другом месте, независимо от того, назначены ли они, и действительно ли результат «равно» фактически сохраняется или используется, может сильно повлиять на то, какой код компилятор решает вывести. – Pharap
Этот способ мышления о программировании заставит вас писать нечитаемый код без увеличения производительности. – Radiodef