آہ، یہ لائنیں...

java.lang.String کلاس شاید جاوا میں سب سے زیادہ استعمال ہونے والی کلاسوں میں سے ایک ہے۔ اور اکثر یہ بے ادبی سے استعمال ہوتا ہے، جو بہت سے مسائل کو جنم دیتا ہے، بنیادی طور پر کارکردگی کے ساتھ۔ اس مضمون میں میں تاروں، ان کے استعمال کی پیچیدگیوں، مسائل کے ذرائع وغیرہ کے بارے میں بات کرنا چاہتا ہوں۔ یہاں ہم اس کے بارے میں بات کریں گے:

• لائن ڈیوائس
• سٹرنگ لٹریلز
• سٹرنگ کا موازنہ
• سٹرنگ کا اضافہ
• سبسٹرنگ فیچ اور کاپی کنسٹرکٹر
• ایک تار کو تبدیل کرنا
• آئیے بنیادی باتوں سے شروع کریں۔

لائن ڈیوائس

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 )۔ یونیکوڈ UTF-16BE انکوڈنگ کو میموری میں حروف کو اسٹور کرتے وقت استعمال کیا جاتا ہے ۔ آپ یہاں اس کے بارے میں مزید پڑھ سکتے ہیں ۔ جاوا 5.0 کے ساتھ شروع کرتے ہوئے، 2 سے اوپر کے یونیکوڈ ورژن کے لیے سپورٹ اور، اسی کے مطابق، 0xFFFF سے زیادہ کوڈ والے حروف کے لیے متعارف کرایا گیا ہے ۔ ان حروف کے لیے، ایک حرف استعمال نہیں کیا جاتا ، بلکہ دو؛ ان حروف کی انکوڈنگ کے بارے میں مزید تفصیلات اسی مضمون میں ہیں ۔ اگرچہ ان علامتوں کی حمایت متعارف کرائی گئی ہے، لیکن مسئلہ یہ ہے کہ وہ ظاہر نہیں ہوں گے۔ مجھے موسیقی کی علامتوں کا ایک سیٹ ملا ( U1D100 ) اور میں نے کہیں ٹریبل کلیف کو ظاہر کرنے کی کوشش کی (کوڈ 1D120 کے ساتھ علامت)۔ میں نے کوڈ کو دو حروف میں تبدیل کیا ، جیسا کہ توقع کی گئی ہے - '\uD834' اور '\uDD20'۔ ڈیکوڈر ان کے بارے میں شکایت نہیں کرتا؛ یہ ایمانداری سے انہیں ایک کردار کے طور پر پہچانتا ہے۔ لیکن ایسا کوئی فونٹ نہیں ہے جس میں یہ علامت موجود ہو۔ اور اس وجہ سے - ایک مربع. اور بظاہر، یہ ایک طویل وقت تک رہے گا. اس لیے یونیکوڈ 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;

/**
 * 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 لہذا، حقیقی ایپلی کیشنز میں، میں آپ کو مشورہ دیتا ہوں کہ حفاظتی پالیسیاں ترتیب دینے کے لیے زیادہ محتاط انداز اختیار کریں۔ بصورت دیگر، یہ معلوم ہو سکتا ہے کہ وہ اشیاء جن کے بارے میں آپ کے خیال میں ناقابل تغیر ہونے کی ضمانت دی گئی ہے۔ * * * میرا اندازہ ہے کہ میں ابھی سٹرنگز کے بارے میں اتنا ہی کہنا چاہتا ہوں۔ آپکی توجہ کا شکریہ! اصل ماخذ سے لنک: آہ، یہ سطریں...