啊，這些線...

在 Random-TW 群組發布

java.lang.String 類別可能是 Java 中最常用的類別之一。而且它經常被不識字地使用，這會引起許多問題，主要是性能方面的問題。在這篇文章中，我想談談字串、使用它們的複雜性、問題的根源等。

我們將討論以下內容：

線路裝置
字串文字
字串比較
字串加法
子字串取得和複製建構函數
換一條線
讓我們從基礎開始。

線路裝置

java.lang.String類別包含三個字段：

/**
 * NOTE: This is just a partial API
 */
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 支援的引入只能透過未來基礎的棱鏡來看待。讓我們更進一步。我請您密切注意第二個和第三個欄位 - offset和count。如果使用了所有字符，則數組似乎完全定義了字串。如果存在此類字段，則並非可以使用數組中的所有字元。確實如此，我們將在子字串選擇和複製構造函數部分討論這一點。

字串文字

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;

/**
 * This application demonstrates how to modify java.lang.String object
 * through reflection API.
 *
 * @version 1.0
 * @author Eugene Matyushkin
 */
public class StringReverseTest {

    /**
     * final static string that should be modified.
     */
    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. 因此，在實際應用中，我建議您在設定安全策略時採取更謹慎的方法。否則，您認為保證不可變的物件可能並非如此。* * * 我想這就是我現在要說的關於字串的全部內容。感謝您的關注！ 連結到原始來源：啊，這些行......