La clase
java.lang.String es quizás una de las más utilizadas en Java. Y muy a menudo se utiliza de forma analfabeta, lo que genera muchos problemas, principalmente de rendimiento. En este artículo quiero hablar sobre cadenas, las complejidades de su uso, las fuentes de los problemas, etc.
Esto es de lo que hablaremos:
- Dispositivo de línea
- Literales de cadena
- Comparación de cadenas
- Adición de cadenas
- Constructor de recuperación y copia de subcadenas
- Cambiando una línea
- Empecemos con lo básico.
Dispositivo de línea
La clase
java.lang.String contiene tres campos:
public final class String{
private final char value[];
private final int offset;
private final int count;
}
De hecho, también contiene otros campos, por ejemplo, un código hash, pero esto no es importante ahora. Los principales son estos. Entonces, la base de una cadena es una matriz de caracteres (
char ).
La codificación Unicode UTF-16BE se utiliza al almacenar caracteres en la memoria . Puedes leer más sobre esto
aquí . A partir de Java 5.0, se introdujo soporte para versiones Unicode superiores a 2 y, en consecuencia, para caracteres con códigos mayores que
0xFFFF . Para estos caracteres no se utiliza un
carácter , sino dos; más detalles sobre la codificación de estos caracteres
se encuentran en el mismo artículo . Aunque se ha introducido soporte para estos símbolos, el problema es que no se mostrarán. Encontré un conjunto de símbolos musicales (
U1D100 ) e intenté mostrar la clave de sol en algún lugar (símbolo con código 1D120). Convertí el código en dos
caracteres , como se esperaba: '\uD834' y '\uDD20'. El decodificador no se queja de ellos; honestamente los reconoce como un solo personaje. Pero no existe ninguna fuente en la que exista este símbolo. Y por lo tanto - un cuadrado. Y aparentemente esto durará mucho tiempo. Por lo tanto, la introducción del soporte para Unicode 4 puede verse únicamente a través del prisma de una base para el futuro. Vayamos más lejos. Les pido que presten mucha atención al segundo y tercer campo:
compensación y
recuento . Parecería que la matriz define completamente la cadena si se usan
TODOS los caracteres. Si dichos campos existen, no se podrán utilizar todos los caracteres de la matriz. Así es, hablaremos de esto en la sección de selección de subcadenas y constructor de copias.
Literales de cadena
Qué такое строковый литерал? Это строка, записаная в двойных кавычках, например, такая: "abc". Такие выражения используются в códigoе сплошь и рядом. Строка эта может содержать escape-последовательности unicode, например, \u0410, что будет соответствовать русской букве 'А'. Однако, эта строка
НЕ МОЖЕТ содержать последовательностей \u000A и \u000D, соответствующие символам LF и CR соответственно. Дело в том, что последовательности обрабатываются на самой ранней стадии компиляции, и символы эти будут заменены на реальные LF и CR (Cómo если бы в редакторе просто нажали "Enter"). Для вставки в строку этих символов следует использовать последовательности \n и \r, соответственно. Строковые литералы сохраняются в пуле строк. Я упоминал о пуле в статье о сравнении на практике, но повторюсь. Виртуальная машина Java поддерживает пул строк. В него кладутся все строковые литералы, объявленные в códigoе. При совпадении литералов (с точки зрения equals, см.
тут) используется один и тот же un objeto, находящийся в пуле. Это позволяет сильно экономить память, а в некоторых случаях и повышать производительность. Дело в том, что строку в пул можно поместить принудительно, с помощью метода
String.intern(). Этот метод возвращает из пула строку, равную той, у которой был вызван этот метод. Если же такой строки нет – в пул кладется та, у которой вызван метод, после чего возвращается enlace на нее же. Таким образом, при грамотном использовании пула появляется возможность сравнивать строки не по значению, через equals, а по ссылке, что значительно, на порядки, быстрее. Так реализован, например, класс
java.util.Locale, который имеет дело с кучей маленьких, в основном двухсимвольных, строк – códigoами стран, языков и т.п. См. также тут:
Сравнение un objetoов: практика – метод String.intern. Очень часто я вижу в различной литературе конструкции следующего вида:
public static final String SOME_STRING = new String("abc");
Если говорить еще точнее, нарекания у меня вызывает
new String("abc"). Дело в том, что конструкция эта – безграмотна. В Java строковый литерал – "abc" –
УЖЕ является un objetoом класса
String. А потому, использование еще и конструктора приводит к
КОПИРОВАНИЮ строки. Поскольку строковый литерал уже хранится в пуле, и никуда из него не денется, то созданный
НОВЫЙ un objeto – ничто иное Cómo пустая трата памяти. Эту конструкцию с чистой совестью можно переписать вот так:
public static final String SOME_STRING = "abc";
С точки зрения códigoа это будет абсолютно то же самое, но несколько эффективнее. Переходим к следующему вопросу –
Сравнение строк
Собственно, все об этом вопросе я уже писал в статье
Сравнение un objetoов: практика. И добавить больше нечего. Резюмируя сказаное там – строки надо сравнивать по значению, с использованием метода
equals. По ссылке их можно сравнивать, но аккуратно, только если точно знаешь, что делаешь. В этом помогает метод
String.intern. Единственный момент, который хотелось бы упомянуть – сравнение с литералами. Я часто вижу конструкции типа
str.equals("abc"). И тут есть небольшие грабли – перед этим сравнением правильно бы было сравнить
str с
null, чтобы не получить
NullPointerException. Т.е. правильной будет конструкция
str != null && str.equals("abc"). Между тем – ее можно упростить. Достаточно написать всего лишь
"abc".equals(str). Проверка на
null в этом случае не нужна. На очереди у нас...
Сложение строк
Строки – единственный un objeto, для которого определена операция сложения ссылок. Во всяком случае, так было до версии Java 5.0, в которой появился autoboxing/unboxing, но речь сейчас не об этом. Общее описание принципа работы оператора конкатенации можно найти в статье о enlaceх, а именно –
тут. Я же хочу затронуть более глубокий уровень. Представьте себе, представьте себе... Прямо Cómo в песенке про кузнечика. :) Так вот, представьте себе, что нам надо сложить две строки, вернее, к одной прибавить другую:
String str1 = "abc";
str1 += "def";
Как происходит сложение? Поскольку un objeto класса строки неизменяем, то результатом сложения будет новый un objeto. Итак. Сначала выделяется память, достаточная для того, чтобы вместить туда содержимое обеих строк. В эту память копируется содержимое сначала первой строки, потом второй. Далее переменной str1 присваивается enlace на новую строку, а старая строка отбрасывается. Усложним задачу. Пусть у нас есть файл из четырех строк:
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 присваивается enlace на новую строку, старая отбрасывается. Второй проход цикла.
result="abc",
line="def". Выделяется память на 6 символов, туда копируется содержимое
result –
"abc", затем
line –
"def". Переменной
result присваивается enlace на новую строку, старая отбрасывается. Третий проход цикла.
result="abcdef",
line="ghi". Выделяется память на 9 символов, туда копируется содержимое
result –
"abcdef", затем
line –
"ghi". Переменной
result присваивается enlace на новую строку, старая отбрасывается. Четвертый проход цикла.
result="abcdefghi",
line="jkl". Выделяется память на 12 символов, туда копируется содержимое
result –
"abcdefghi", затем
line –
"jkl". Переменной
result присваивается enlace на новую строку, старая отбрасывается. Пятый проход цикла.
result="abcdefghijkl",
line=null. Цикл закончен. Итак. Три символа "abc" копировались в памяти 4 раза, "def" – 3 раза, "ghi" – 2 раза, "jkl" – один раз. Страшно? Не особо? А вот теперь представьте себе файл с длиной строки 80 символов, в котором где-то 1000 строк. Всего-навсего 80кб. Представo? Qué будет в этом случае? первая строка, Cómo нетрудно подсчитать, будет скопирована в памяти 1000 раз, вторая – 999 и т.д. И при средней длине 80 символов через память пройдет ((1000 + 1) * 1000 / 2) * 80 = ... барабанная дробь... 40 040 000 символов, что составляет около 80 Мб (!!!) памяти. Каков же итог
ТАКОГО цикла? Чтение 80-килоbyteного archivo вызвало выделение 80 Мб памяти. Ни много ни мало – в 1000 раз больше, чем полезный объем. Какой из этого следует сделать вывод? Очень простой. Никогда, запомните –
НИКОГДА не используйте прямую конкатенацию строк, особенно в циклах. Даже в Cómoом-нибудь методе
toString, если он вызывается достаточно часто, имеет смысл использовать
StringBuffer en lugar de конкатенации. Собственно, компилятор при оптимизации чаще всего так и делает – прямые сложения он выполняет через
StringBuffer. Однако в случаях, подобных тому, что привел я, оптимизацию компилятор сделать не в состоянии. Qué и приводит к весьма печальным последствиям, описаным чуть ниже. К сожалению, подобные конструкции встречаются слишком часто. Потому я и счел необходитмым заострить на этом внимание.
Собственный опыт Не могу не вспомнить один эпизод из собственной практики. Один из программистов, работавших со мной, Cómo-то пожаловался, что у него очень медленно работает его código. Он читал достаточно большой файл в HTML формате, после чего производил Cómoие-то манипуляции. И действительно, работало все с черепашьей velocidadю. Я взял посмотреть исходник, и обнаружил, что он... использует конкатенацию строк. У него было по 200-250 строк в каждом файле, и при чтении archivo около 200Кб через память проходило более 40Мб! В итоге я переписал немного código, заменив операции со строками на операции со StringBuffer-ом. Честно сказать, когда я запустил переписаный código, я подумал, что он просто где-то "упал". Обработка занимала доли секунды. Скорость выросла в 300-800 раз. После этого я коренным образом пересмотрел свое отношение к строковым операциям. Следующий акт марлезонского балета –
Выборка подстроки и копирующий конструктор
Представим, что у нас есть строка, из которой надо вырезать подстроку. Вопроса "Cómo это сделать" не стоит – и так понятно. Вопрос в другом – что при этом происходит?
String str = "abcdefghijklmnopqrstuvwxyz";
str = str.substring(5,10);
Вроде тривиальный código. И первая мысль такая – выбирается подстрока "efghi", переменной str присваивается enlace на новую строку, а старый un objeto отбрасывается. Так? Почти. Дело в том, что для увеличения скорости при выборке подстроки используется ТОТ ЖЕ МАССИВ, что и в исходной строке. Иначе говоря, мы получим не un objeto, в котором массив
value (cм.
устройство строки) имеет длину 5 и содержит в себе символы 'e', 'f', 'g', 'h' и 'i', count=5 и offset=0. Нет, длина массива будет по-прежнему 26, count=5 и offset=5. И при отбрасывании старой строки массив НЕ ОТБРОСИТСЯ, а по-прежнему будет находиться в памяти, ибо на него есть enlace из новой строки. И существовать в памяти он будет до того момента, Cómo будет отброшена уже новая строка. Это совсем неочевидный момент, который может привести к проблемам с памятью. Возникает вопрос – Cómo этого избежать? Ответ – с помощью копирующего конструктора
String(String). Дело в том, что в этом конструкторе в явном виде выделяется память под новую строку, и в эту память копируется содержимое исходной. Таким образом, если мы перепишем código так:
String str = "abcdefghijklmnopqrstuvwxyz";
str = new String(str.substring(5,10));
..., то длина массива
value у un objetoа
str будет действительно 5, count=5 и offset=0. И это – единственный случай, где оправдано применение копирующего конструктора для строки. И Cómo финальный аккорд –
Изменение строки
Esto poco tiene que ver con la línea como tal. Sólo quiero resaltar el hecho de que una cadena es inmutable sólo hasta cierto punto. Así que aquí está el código.
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
¿Que está pasando aqui? Primero estoy buscando un campo de tipo
char[] . También podría buscar por nombre. Sin embargo, el nombre puede cambiar, pero dudo mucho del tipo. A continuación, llamo al método
setAccessible(true) en el campo encontrado . Este es un punto clave: desactivo la verificación del nivel de acceso al campo (de lo contrario, simplemente no podré cambiar el valor porque el campo es
privado ). En este punto, el gerente de seguridad puede golpearme en la cabeza y verificar si dicha acción está permitida (mediante una llamada a
checkPermission(new ReflectPermission("suppressAccessChecks")) ). Si está permitido (y este es el valor predeterminado para aplicaciones normales), puedo acceder al campo
privado . El resto, como suele decirse, es cuestión de técnica. Como resultado obtengo el resultado:
Initial static final string: abcde
Reversed static final string: edcba
Q.E.D. Por lo tanto, en aplicaciones reales, le aconsejo que tenga más cuidado al configurar las políticas de seguridad. De lo contrario, puede resultar que los objetos que usted cree que son inmutables no lo sean. * * * Supongo que eso es todo lo que quiero decir sobre las cadenas por ahora. ¡Gracias por su atención!
Enlace a la fuente original: Ah, estas líneas...
GO TO FULL VERSION