Я считаю, что все хорошо понимают разницу между String и StringBuffer, но, по оценкам, есть еще много товарищей, которым не совсем понятны принципы работы этих двух классов. Сегодня я рассмотрю эту концепцию для всех, и автором. то, как в J2SE 5.0 появился новый класс манипулирования символами — StringBuilder (не спешите забрасывать меня кирпичами, я еще трезв, я не говорю здесь о C#, в Java тоже есть класс StringBuilder). Так в чем же разница между StringBuilder и StringBuffer и классом String, с которым мы впервые познакомились? Какой из них следует использовать в разных ситуациях? Я хотел бы поделиться своими взглядами на эти категории, а также надеюсь, что каждый сможет высказать свое мнение. Каждый совершал ошибки, и их исправление — это хорошая возможность учиться.
Короче говоря, основная разница в производительности между типом String и типом StringBuffer на самом деле заключается в том, что String является неизменяемым объектом (Почему? Спросите разработчиков Java, почему String не является собственным типом?) Поэтому каждый раз, когда тип String изменяется Фактически, это эквивалентно созданию нового объекта String и последующему указанию указателя на новый объект String. Поэтому лучше не использовать String для строк, содержимое которых часто меняется. , потому что каждый раз, когда создается объект, это влияет на производительность системы. Особенно, когда в памяти слишком много объектов, на которые нет ссылок, сборщик мусора JVM начнет работать, и скорость определенно будет довольно низкой. Вот пример, который не очень уместен:
Строка S1 = «abc»;
For(int I = 0; I < 10000; I++) // For имитирует множественные вызовы программы
{
S1+ = «Защита»;
S1 = «абв»;
}
Если это так, то после завершения цикла for, если объекты в памяти не были очищены сборщиком мусора, в памяти их будет более 20 000, поразительное число, и если это система, используемая многими человек, то это число не очень велико, поэтому каждый должен быть осторожен при его использовании.
Если вы используете класс StringBuffer, результаты будут разными. Каждый раз результатом будет операция над самим объектом StringBuffer вместо создания нового объекта и последующего изменения ссылки на объект. Поэтому в целом мы рекомендуем использовать StringBuffer, особенно если строковые объекты часто изменяются. В некоторых особых случаях конкатенация строк объектов String фактически интерпретируется JVM как конкатенация объектов StringBuffer, поэтому в этих случаях скорость объектов String не будет медленнее, чем у объектов StringBuffer, и особенно следующие строковые объекты: генерируется. Среди них эффективность String намного быстрее, чем StringBuffer:
Строка S1 = «Это всего лишь» + «простой» + «тест»;
StringBuffer Sb = new StringBuilder("Это всего лишь").append("простой").append("тест");
Вы будете удивлены, обнаружив, что скорость генерации объектов String S1 просто слишком высока, а на данный момент StringBuffer вообще не имеет преимущества в скорости. На самом деле это уловка JVM. В глазах JVM это так.
String S1 = «Это всего лишь» + «простой» + «тест»; На самом деле это: String S1 = «Это всего лишь простой тест» Так что, конечно, это не займет много времени; Но здесь каждый должен отметить, что если ваша строка получена из другого объекта String, скорость будет не такой высокой, например:
Строка S2 = «Это всего лишь»;
Строка S3 = «простой»;
Строка S4 = «тест»;
Строка S1 = S2 +S3 + S4;
В это время JVM будет вести себя оригинальным образом, а скорость генерации объектов S1 будет не такой высокой, как раньше. Мы можем провести тест, чтобы проверить это позже.
Отсюда мы получаем первый вывод: в большинстве случаев StringBuffer > String
И как StringBuilder сравнивается с ними? Позвольте мне сначала кратко представить его. StringBuilder — это новый класс в JDK5.0. Разница между ним и StringBuffer заключается в следующем (источник: JavaWorld):
Java.lang.StringBuffer Потокобезопасная изменяемая последовательность символов. Строковый буфер, аналогичный String, но не подлежащий изменению. Строковые буферы могут безопасно использоваться несколькими потоками. При необходимости эти методы можно синхронизировать, так что все операции над любым конкретным экземпляром выполняются в последовательном порядке, соответствующем порядку вызовов методов, выполняемых каждым задействованным потоком.
Каждый строковый буфер имеет определенную емкость. Пока длина последовательности символов, содержащейся в строковом буфере, не превышает эту емкость, нет необходимости выделять новый внутренний массив буферов. Эта емкость автоматически увеличивается при переполнении внутреннего буфера. Начиная с JDK 5.0, к этому классу был добавлен эквивалентный класс для однопоточного использования — StringBuilder. Класс StringBuilder обычно следует использовать вместо этого класса, поскольку он поддерживает все те же операции, но работает быстрее, поскольку не выполняет синхронизацию.
Но использовать экземпляр StringBuilder с несколькими потоками небезопасно. Если такая синхронизация требуется, рекомендуется использовать StringBuffer.
С учетом вышесказанного, я думаю, каждый может понять разницу между ними, поэтому давайте сделаем общий вывод ниже:
В большинстве случаев StringBuilder > StringBuffer
Поэтому по теореме переноса этого неравенства: в большинстве случаев StringBuilder > StringBuffer > String (чем больше операций, тем стабильнее).
Получите системное время long start = System.currentTimeMillis(); long end = System.currentTimeMillis(); чтобы узнать текущее значение миллисекунды.
for(i=0;i<str.length()/2;i++)
if(str.charAt(i)!=str.charAt(str.length()-i-1))
перерыв;
если(я>=str.length()/2)
JOptionPane.showMessageDialog(null, «является строкой-палиндромом»);
еще
JOptionPane.showMessageDialog(null, «Не строка-палиндром»);
}
}
*/
если(str.equals(str2))
JOptionPane.showMessageDialog(null, «является строкой-палиндромом»);
еще
JOptionPane.showMessageDialog(null, «Не строка-палиндром»);
}
}