Java BufferedReader назад к вершине текстового файла?
Указатель NULL - это тот, который указывает на никуда. Когда вы разыскиваете указатель p, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p является нулевым указателем, местоположение, хранящееся в p, является nowhere, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception.
В общем, это потому, что что-то не было правильно инициализировано.
5 ответов
Каков недостаток просто создания нового BufferedReader для чтения из вершины? Я ожидал бы, что операционная система будет кэшировать файл, если это является достаточно маленьким.
, Если Вы обеспокоены производительностью, Вы доказали его, чтобы быть узким местом? Я просто сделал бы самую простую вещь и не волновался бы об этом, пока у Вас нет определенной причины для. Я имею в виду, Вы могли просто считать все это в память и затем сделать эти два передают результат, но снова это будет более сложным, чем просто чтение из запуска снова с новым читателем.
Буферизированные читатели предназначены для чтения файла последовательно. То, что Вы ищете, java.io. RandomAccessFile, и затем можно использовать seek() для взятия Вас туда, где Вы хотите в файле.
средство чтения произвольного доступа реализовано как так:
try{
String fileName = "c:/myraffile.txt";
File file = new File(fileName);
RandomAccessFile raf = new RandomAccessFile(file, "rw");
raf.readChar();
raf.seek(0);
} catch (FileNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Эти "rw" символ режима, который является подробный здесь .
причина с последовательным доступом читатели являются установкой как это, то, так, чтобы они могли реализовать свои буферы и это, вещи не могут быть изменены под их ногами. Например, на средстве чтения файлов, которое дано буферизированному читателю, должен только управлять тот буферизированный читатель. Если бы было другое местоположение, которое могло бы влиять на него, то Вы могли перенести непоследовательную операцию, поскольку один читатель усовершенствовал ее положение в средстве чтения файлов, в то время как другой требуемый это, чтобы остаться тем же теперь Вы используете другого читателя, и это находится в неопределенном месте.
Лучший способ продолжиться состоит в том, чтобы изменить Ваш алгоритм, способом в котором Вам НЕ будет нужна вторая передача. Я использовал этот подход пару раз, когда я должен был иметь дело с огромным (но не ужасный, т.е. немного ГБ) файлы, которые не соответствовали доступной памяти.
Это могло бы быть твердо, но увеличение производительности обычно ценность усилие
О метке/сбросе:
метод метки в BufferedReader берет readAheadLimit параметр, который ограничивает, как далеко можно читать после метки, прежде чем сброс становится невозможным. Сброс на самом деле не означает, что файловая система ищет (0), это просто ищет в буфере. Заключить Javadoc в кавычки:
readAheadLimit - Предел на количество символов, которые могут быть считаны, все еще сохраняя метку. После чтения этого могут перестать работать много символов, пытаясь сбросить поток. Предельное значение, больше, чем размер входного буфера, заставит новый буфер быть выделенным, чей размер не меньше, чем предел. Поэтому большие значения должны использоваться с осторожностью.
"Целый бизнес о метке () и сброс () во вкусах BufferedReader плохого дизайна".
, почему Вы не расширяете этот класс и имеете его, делают метку () в конструкторе () и затем делают искание (0) в topOfFile () метод.
BR,
~A