Недавно, когда я искал работу, экзаменатор задал мне простой вопрос: «Разница между StringBuffer и StringBuilder, каковы их сценарии приложения?» Ответ редактора разделен с вами ниже, так что для всех может быть удобно учиться в будущем, чтобы сделать запись.
На самом деле, просто ищите Google Master, и у вас будет ответ: StringBuffer полностью эквивалентен методам и функциям в StringBuilder, но большинство методов в StringBuffer используют синхронизированное ключевое слово для модификации, поэтому они безопасны для потока. Без этой модификации StringBuilder можно считать потоком.
Чтобы лучше понять вышеупомянутый ответ, лучше прямо увидеть, что реализация исходного кода StringBuffer и StringBuilder более реалистична. Как программист, «если у вас есть какие -либо вопросы, посмотрите на исходный код» - правильный путь. Я могу сказать ответственно, конечно, у вас должны быть условия!
В реализации JDK и StringBuffer, и StringBuilder наследуются от AbstractStringBuilder. Для безопасности и небезопасности многопоточного, у вас будет грубое понимание синхронизированных методов в StringBuffer.
Здесь я кратко расскажу о принципе реализации AbstractStringBuilder: мы знаем, что использование StringBuffer - это не что иное, как для повышения эффективности струнного соединения в Java, потому что, если вы используете + непосредственно для строкового соединения, JVM создаст несколько строковых объектов, что вызовет определенные накладные расходы. AbstractStringBuilder использует массив Char, чтобы сохранить строку, которую необходимо добавить. Массив char имеет начальный размер. Когда длина строки строки приложения превышает текущую емкость массива char, массив char динамически расширяется, то есть повторное применение более широкого пространства памяти, а затем копирование текущего массива char в новое место. Поскольку накладные расходы повторного распределения памяти и копирования являются относительно велики, каждый раз, когда вы подаете на повторное применение пространства памяти, в том, что пространство памяти больше, чем требуемый ток, что в 2 раза.
Далее, повеселиться!
Вот некоторая информация в Google:
【
StringBuffer начался с JDK 1.0
StringBuilder начал с JDK 1.5
Начиная с JDK 1.5, операция подключения (+) со строковыми переменными используется внутренне JVM
StringBuilder реализован, и эта операция была реализована с использованием StringBuffer.
】
Мы смотрим на процесс выполнения с помощью простой программы:
Список 1 Buffer.java
открытый класс буфер {public static void main (string [] args) {string s1 = "aaaaa"; String s2 = "bbbbbb"; Строка r = null; int i = 3694; R = S1 + I + S2; for (int j = 0; i <10; j ++) {r+= "23124"; }}}Используйте буфер команды Javap -c для просмотра его реализации Bytecode:
Список 2 буферных классов Bytecode
Соответствующий список 1 и список 2, инструкция LDC в списке 2 загружает строку «aaaa» из постоянного пула в верхнюю часть стека, а Istore_1 хранит «Aaaaa» в переменной 1. Ниже одинаково. Sipush подталкивает краткое целочисленное постоянное значение (-32768 ~ 32767) в верхнюю часть стека. Вот постоянная "3694". Для получения дополнительных наборов инструкций Java, пожалуйста, проверьте еще одну статью «Набор инструкций Java».
Давайте непосредственно увидим, что 13, 13 ~ 17 новичок в объекте StringBuffer и вызовут его метод инициализации. 20 ~ 21 - сначала нажать переменную 1 в верхнюю часть стека через ALOAD_1. Как упоминалось ранее, переменная 1 помещается в строку постоянную «aaaaa», а затем вызывает метод добавления Stringbuffer через инструкцию Invokevirtual, чтобы объединить «aaaaa» вместе. Следующие 24 ~ 30 это то же самое. Наконец, в 33 функция ToString в StringBuffer вызывается, чтобы получить результат строки и хранить в переменной 3 через магазин.
Когда мы видим это, кто -то может сказать: «Поскольку JVM использует StringBuffer для подключения строк, нам не нужно использовать StringBuffer сами, просто используйте«+«просто!» Это правда? Конечно, нет. Как говорится, «Есть причина существования», давайте продолжим смотреть на байт -код, соответствующий последующему циклу.
37 ~ 42 - все некоторые препараты перед входом в петлю. 37, 38 SET J TO 1. 44 Здесь, if_icmpge сравнивает j с 10. Если J больше 10, он будет прыгать непосредственно на 73, то есть оператор возврата выходит из функции; В противном случае он входит в петлю, то есть байт -код 47 ~ 66. Здесь нам нужно только взглянуть на 47-51, чтобы узнать, почему мы используем StringBuffer в нашем коде для обработки строковых соединений, потому что каждый раз, когда мы выполняем операцию «+», JVM имеет новый объект StringBuffer для обработки строковых соединений, что будет очень дорого, когда будет задействовано много операций строковых соединений.