คลาส
java.lang.Stringอาจเป็นหนึ่งในคลาสที่มีการใช้งานมากที่สุดใน Java และบ่อยครั้งมากที่มันถูกใช้อย่างไม่รู้หนังสือ ซึ่งก่อให้เกิดปัญหามากมาย โดยหลักๆ คือเรื่องประสิทธิภาพ ในบทความนี้ ฉันต้องการพูดคุยเกี่ยวกับสตริง ความซับซ้อนของการใช้สตริง แหล่งที่มาของปัญหา ฯลฯ
เราจะพูดถึงเรื่องนี้:
- อุปกรณ์สาย
- ตัวอักษรสตริง
- การเปรียบเทียบสตริง
- การเพิ่มสตริง
- ตัวสร้างการดึงและคัดลอกสตริงย่อย
- การเปลี่ยนบรรทัด
- เริ่มจากพื้นฐานกันก่อน
อุปกรณ์สาย
คลาส
java.lang.Stringมีสามฟิลด์:
public final class String{
private final char value[];
private final int offset;
private final int count;
}
อันที่จริงแล้ว ยังมีช่องอื่นๆ ด้วย เช่น รหัสแฮช แต่ตอนนี้ไม่สำคัญแล้ว สิ่งสำคัญคือสิ่งเหล่านี้ ดังนั้นพื้นฐานของสตริงคืออาร์เรย์ของอักขระ (
char )
การเข้ารหัส Unicode UTF-16BEใช้สำหรับจัดเก็บอักขระในหน่วยความจำ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้
ที่นี่ ตั้งแต่ Java 5.0 เป็นต้นไป จะมีการรองรับ Unicode เวอร์ชันที่ สูงกว่า 2 และตามลำดับ สำหรับอักขระที่มีรหัสมากกว่า
0xFFFF สำหรับอักขระเหล่านี้ จะไม่มี การใช้
อักขระ ตัวเดียว แต่ใช้สองตัว รายละเอียดเพิ่มเติมเกี่ยวกับการเข้ารหัสอักขระเหล่านี้
อยู่ในบทความเดียวกัน แม้ว่าจะมีการรองรับสัญลักษณ์เหล่านี้แล้ว แต่ปัญหาก็คือจะไม่แสดงขึ้นมา ฉันพบชุดสัญลักษณ์ดนตรี (
U1D100 ) และพยายามแสดงกุญแจเสียงแหลมที่ไหนสักแห่ง (สัญลักษณ์ที่มีรหัส 1D120) ฉันแปลงรหัสเป็น
ตัวอักษร สองตัว ตามที่คาดไว้ - '\uD834' และ '\uDD20' ตัวถอดรหัสไม่ได้บ่นเกี่ยวกับสิ่งเหล่านี้ แต่จะจดจำพวกมันในฐานะตัวละครตัวเดียวโดยสุจริต แต่ไม่มีแบบอักษรที่มีสัญลักษณ์นี้อยู่ ดังนั้น - สี่เหลี่ยมจัตุรัส และเห็นได้ชัดว่าสิ่งนี้จะคงอยู่เป็นเวลานาน ดังนั้นการแนะนำการสนับสนุน Unicode 4 จึงสามารถดูได้ผ่านปริซึมของรากฐานสำหรับอนาคตเท่านั้น ไปต่อกันดีกว่า ฉันขอให้คุณใส่ใจกับฟิลด์ที่สองและสาม–
ชดเชยและ
นับ ดูเหมือนว่าอาร์เรย์จะกำหนดสตริงโดยสมบูรณ์หากใช้อักขระ
ทั้งหมด หากช่องดังกล่าวมีอยู่ จะไม่สามารถใช้อักขระทุกตัวในอาร์เรย์ได้ เป็นเช่นนั้น เราจะพูดถึงเรื่องนี้ในส่วนการเลือกสตริงย่อยและตัวสร้างการคัดลอก
ตัวอักษรสตริง
What такое строковый литерал? Это строка, записаная в двойных кавычках, например, такая: "abc". Такие выражения используются в codeе сплошь и рядом. Строка эта может содержать escape-последовательности unicode, например, \u0410, что будет соответствовать русской букве 'А'. Однако, эта строка
НЕ МОЖЕТ содержать последовательностей \u000A и \u000D, соответствующие символам LF и CR соответственно. Дело в том, что последовательности обрабатываются на самой ранней стадии компиляции, и символы эти будут заменены на реальные LF и CR (How если бы в редакторе просто нажали "Enter"). Для вставки в строку этих символов следует использовать последовательности \n и \r, соответственно. Строковые литералы сохраняются в пуле строк. Я упоминал о пуле в статье о сравнении на практике, но повторюсь. Виртуальная машина Java поддерживает пул строк. В него кладутся все строковые литералы, объявленные в codeе. При совпадении литералов (с точки зрения equals, см.
тут) используется один и тот же an object, находящийся в пуле. Это позволяет сильно экономить память, а в некоторых случаях и повышать производительность. Дело в том, что строку в пул можно поместить принудительно, с помощью метода
String.intern(). Этот метод возвращает из пула строку, равную той, у которой был вызван этот метод. Если же такой строки нет – в пул кладется та, у которой вызван метод, после чего возвращается link на нее же. Таким образом, при грамотном использовании пула появляется возможность сравнивать строки не по значению, через equals, а по ссылке, что значительно, на порядки, быстрее. Так реализован, например, класс
java.util.Locale, который имеет дело с кучей маленьких, в основном двухсимвольных, строк – codeами стран, языков и т.п. См. также тут:
Сравнение an objectов: практика – метод String.intern. Очень часто я вижу в различной литературе конструкции следующего вида:
public static final String SOME_STRING = new String("abc");
Если говорить еще точнее, нарекания у меня вызывает
new String("abc"). Дело в том, что конструкция эта – безграмотна. В Java строковый литерал – "abc" –
УЖЕ является an objectом класса
String. А потому, использование еще и конструктора приводит к
КОПИРОВАНИЮ строки. Поскольку строковый литерал уже хранится в пуле, и никуда из него не денется, то созданный
НОВЫЙ an object – ничто иное How пустая трата памяти. Эту конструкцию с чистой совестью можно переписать вот так:
public static final String SOME_STRING = "abc";
С точки зрения codeа это будет абсолютно то же самое, но несколько эффективнее. Переходим к следующему вопросу –
Сравнение строк
Собственно, все об этом вопросе я уже писал в статье
Сравнение an objectов: практика. И добавить больше нечего. Резюмируя сказаное там – строки надо сравнивать по значению, с использованием метода
equals. По ссылке их можно сравнивать, но аккуратно, только если точно знаешь, что делаешь. В этом помогает метод
String.intern. Единственный момент, который хотелось бы упомянуть – сравнение с литералами. Я часто вижу конструкции типа
str.equals("abc"). И тут есть небольшие грабли – перед этим сравнением правильно бы было сравнить
str с
null, чтобы не получить
NullPointerException. Т.е. правильной будет конструкция
str != null && str.equals("abc"). Между тем – ее можно упростить. Достаточно написать всего лишь
"abc".equals(str). Проверка на
null в этом случае не нужна. На очереди у нас...
Сложение строк
Строки – единственный an object, для которого определена операция сложения ссылок. Во всяком случае, так было до версии Java 5.0, в которой появился autoboxing/unboxing, но речь сейчас не об этом. Общее описание принципа работы оператора конкатенации можно найти в статье о linkх, а именно –
тут. Я же хочу затронуть более глубокий уровень. Представьте себе, представьте себе... Прямо How в песенке про кузнечика. :) Так вот, представьте себе, что нам надо сложить две строки, вернее, к одной прибавить другую:
String str1 = "abc";
str1 += "def";
Как происходит сложение? Поскольку an object класса строки неизменяем, то результатом сложения будет новый an object. Итак. Сначала выделяется память, достаточная для того, чтобы вместить туда содержимое обеих строк. В эту память копируется содержимое сначала первой строки, потом второй. Далее переменной str1 присваивается link на новую строку, а старая строка отбрасывается. Усложним задачу. Пусть у нас есть файл из четырех строк:
abc
def
ghi
jkl
Нам надо прочитать эти строки и собрать их в одну. Поступаем по той же схеме.
BufferedReader br = new BufferedReader(new FileReader("... filename ..."));
String result = "";
while(true){
String line = br.readLine();
if (line == null) break;
result += line;
}
Вроде пока все хорошо и логично. Давайте разберем, что происходит на нижнем уровне. Первый проход цикла.
result="",
line="abc". Выделяется память на 3 символа, туда копируется содержимое
line –
"abc". Переменной
result присваивается link на новую строку, старая отбрасывается. Второй проход цикла.
result="abc",
line="def". Выделяется память на 6 символов, туда копируется содержимое
result –
"abc", затем
line –
"def". Переменной
result присваивается link на новую строку, старая отбрасывается. Третий проход цикла.
result="abcdef",
line="ghi". Выделяется память на 9 символов, туда копируется содержимое
result –
"abcdef", затем
line –
"ghi". Переменной
result присваивается link на новую строку, старая отбрасывается. Четвертый проход цикла.
result="abcdefghi",
line="jkl". Выделяется память на 12 символов, туда копируется содержимое
result –
"abcdefghi", затем
line –
"jkl". Переменной
result присваивается link на новую строку, старая отбрасывается. Пятый проход цикла.
result="abcdefghijkl",
line=null. Цикл закончен. Итак. Три символа "abc" копировались в памяти 4 раза, "def" – 3 раза, "ghi" – 2 раза, "jkl" – один раз. Страшно? Не особо? А вот теперь представьте себе файл с длиной строки 80 символов, в котором где-то 1000 строк. Всего-навсего 80кб. Представor? What будет в этом случае? первая строка, How нетрудно подсчитать, будет скопирована в памяти 1000 раз, вторая – 999 и т.д. И при средней длине 80 символов через память пройдет ((1000 + 1) * 1000 / 2) * 80 = ... барабанная дробь... 40 040 000 символов, что составляет около 80 Мб (!!!) памяти. Каков же итог
ТАКОГО цикла? Чтение 80-килоbyteного file вызвало выделение 80 Мб памяти. Ни много ни мало – в 1000 раз больше, чем полезный объем. Какой из этого следует сделать вывод? Очень простой. Никогда, запомните –
НИКОГДА не используйте прямую конкатенацию строк, особенно в циклах. Даже в Howом-нибудь методе
toString, если он вызывается достаточно часто, имеет смысл использовать
StringBuffer instead of конкатенации. Собственно, компилятор при оптимизации чаще всего так и делает – прямые сложения он выполняет через
StringBuffer. Однако в случаях, подобных тому, что привел я, оптимизацию компилятор сделать не в состоянии. What и приводит к весьма печальным последствиям, описаным чуть ниже. К сожалению, подобные конструкции встречаются слишком часто. Потому я и счел необходитмым заострить на этом внимание.
Собственный опыт Не могу не вспомнить один эпизод из собственной практики. Один из программистов, работавших со мной, How-то пожаловался, что у него очень медленно работает его code. Он читал достаточно большой файл в HTML формате, после чего производил Howие-то манипуляции. И действительно, работало все с черепашьей speedю. Я взял посмотреть исходник, и обнаружил, что он... использует конкатенацию строк. У него было по 200-250 строк в каждом файле, и при чтении file около 200Кб через память проходило более 40Мб! В итоге я переписал немного code, заменив операции со строками на операции со StringBuffer-ом. Честно сказать, когда я запустил переписаный code, я подумал, что он просто где-то "упал". Обработка занимала доли секунды. Скорость выросла в 300-800 раз. После этого я коренным образом пересмотрел свое отношение к строковым операциям. Следующий акт марлезонского балета –
Выборка подстроки и копирующий конструктор
Представим, что у нас есть строка, из которой надо вырезать подстроку. Вопроса "How это сделать" не стоит – и так понятно. Вопрос в другом – что при этом происходит?
String str = "abcdefghijklmnopqrstuvwxyz";
str = str.substring(5,10);
Вроде тривиальный code. И первая мысль такая – выбирается подстрока "efghi", переменной str присваивается link на новую строку, а старый an object отбрасывается. Так? Почти. Дело в том, что для увеличения скорости при выборке подстроки используется ТОТ ЖЕ МАССИВ, что и в исходной строке. Иначе говоря, мы получим не an object, в котором массив
value (cм.
устройство строки) имеет длину 5 и содержит в себе символы 'e', 'f', 'g', 'h' и 'i', count=5 и offset=0. Нет, длина массива будет по-прежнему 26, count=5 и offset=5. И при отбрасывании старой строки массив НЕ ОТБРОСИТСЯ, а по-прежнему будет находиться в памяти, ибо на него есть link из новой строки. И существовать в памяти он будет до того момента, How будет отброшена уже новая строка. Это совсем неочевидный момент, который может привести к проблемам с памятью. Возникает вопрос – How этого избежать? Ответ – с помощью копирующего конструктора
String(String). Дело в том, что в этом конструкторе в явном виде выделяется память под новую строку, и в эту память копируется содержимое исходной. Таким образом, если мы перепишем code так:
String str = "abcdefghijklmnopqrstuvwxyz";
str = new String(str.substring(5,10));
..., то длина массива
value у an object
str будет действительно 5, count=5 и offset=0. И это – единственный случай, где оправдано применение копирующего конструктора для строки. И How финальный аккорд –
Изменение строки
สิ่งนี้ไม่เกี่ยวข้องกับบรรทัดเช่นนี้ ฉันแค่อยากจะเน้นความจริงที่ว่าสตริงนั้นไม่เปลี่ยนรูปในระดับหนึ่งเท่านั้น นี่คือรหัส
package tests;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
public class StringReverseTest {
public static final String testString = "abcde";
public static void main(String[] args) {
try{
System.out.println("Initial static final string: "+testString);
Field[] fields = testString.getClass().getDeclaredFields();
Field value = null;
for(int i=0; i
เกิดอะไรขึ้นที่นี่? ก่อนอื่นฉันกำลังมองหาฟิลด์ประเภท
char[ ] ฉันก็สามารถค้นหาตามชื่อได้เช่นกัน อย่างไรก็ตามชื่ออาจมีการเปลี่ยนแปลง แต่ฉันสงสัยอย่างมากถึงประเภทนั้น ต่อไป ฉันจะเรียกใช้ เมธอด
setAccessible(true) ในฟิลด์ ที่ พบ นี่คือจุดสำคัญ - ฉันปิดการใช้งานการตรวจสอบระดับการเข้าถึงสำหรับฟิลด์ (ไม่เช่นนั้น ฉันก็จะไม่สามารถเปลี่ยนค่าได้ เนื่องจากฟิลด์เป็น
แบบส่วนตัว ) ณ จุดนี้ฉันอาจถูกผู้จัดการความปลอดภัยโจมตีซึ่งตรวจสอบว่าการกระทำดังกล่าวได้รับอนุญาตหรือไม่ (ผ่านการเรียกไป checkPermission
(new ReflectPermission("suppressAccessChecks")) ) หากได้รับอนุญาต (และเป็นค่าเริ่มต้นสำหรับแอปพลิเคชันทั่วไป) ฉันสามารถเข้าถึงฟิลด์
ส่วนตัว ได้ อย่างที่พวกเขาพูดที่เหลือเป็นเรื่องของเทคนิค เป็นผลให้ฉันได้ผลลัพธ์:
Initial static final string: abcde
Reversed static final string: edcba
Q.E.D. ดังนั้นในการใช้งานจริง ฉันขอแนะนำให้คุณตั้งค่านโยบายความปลอดภัยอย่างระมัดระวังมากขึ้น มิฉะนั้น อาจกลายเป็นว่าวัตถุที่คุณคิดว่ารับประกันได้ว่าจะไม่เปลี่ยนรูปนั้นไม่เป็นเช่นนั้น * * * ฉันเดาว่านั่นคือทั้งหมดที่ฉันอยากจะพูดเกี่ยวกับสตริงในตอนนี้ ขอขอบคุณสำหรับความสนใจของคุณ!
ลิงก์ไปยังแหล่งที่มาดั้งเดิม: อ่า บรรทัดเหล่านี้...
GO TO FULL VERSION