JavaRush/Помощь по Java задачам/Использование метода available(), для проверки достижения...

18 уровень

13.04.2021
3162просмотров
17комментариев

Использование метода available(), для проверки достижения конца файла.

Решен

Здравствуйте! Хотелось бы выяснить у опытных товарищей следующий момент: Часто вижу, что для проверки достижения конца файла, используют метод available() класса FileInputStream. Мой вопрос заключается в следующем: А может ли сложится такая ситуация, когда вызов метода available() класса FileInputStream возвратит значение 0, до достижения конца файла? Просто в описании метода available() абстрактного класса InputStream, который является базовым классом для FileInputStream, сказано следующее: "Returns an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking, which may be 0, or 0 when end of stream is detected."

Комментарии (17)

популярные
новые
старые

Для того, чтобы оставить комментарий Вы должны авторизоваться

fog

Уровень 18

14 апреля 2021, 08:51

Пока читал эту статью, подумал, а что будет возвращать метод available(), если в качестве файла-источника указать псевдоустройство /dev/random? Проверил в jshell - оказалось стабильно возвращает значение 0, хотя до "конца файла" ещё очень далеко ;). Тот же эффект наблюдается и в отношении других псевдоустройств, таких как /dev/urandom и /dev/null. Написал небольшой тест:

import java.io.FileInputStream;
import java.io.IOException;

public class AvailableTest {
	private static final String SRC_FILE = "/dev/random";
	public static void main (final String ... args) throws IOException {
		try (final FileInputStream fis = new FileInputStream(SRC_FILE)) {
			final int avalableBytes = fis.available();
			final int value = fis.read();
			System.out.println("In file \"" + SRC_FILE + "\" is available " + avalableBytes  + " bytes.");
			System.out.println("The value " + value + " was read from the file.");
		} // end try
	} // end method main(String[])
} // end class AvailableTest

Данный код, также стабильно выдаёт значение 0.

Wladyslaw Java Developer

Master

13 апреля 2021, 16:44

решение

Насколько я понимаю - когда ты читаешь из файловой системы с помощью FileInputStream - то нет, не может. Весь файл будет вычитан без блокировок. Хотя, тут нужно смотреть какие файловые системы как работают и какие гарантии дают. А вот другие реализации, при чтении из какого-то сокета, например - вполне. Ноль вернули - в данный момент читать нечего, но возможно ещё будет.

fog

Уровень 18

13 апреля 2021, 16:47

Благодарю. О чём-то подобном я и подозревал.

Wladyslaw Java Developer

Master

13 апреля 2021, 16:57

полезный

Вот тут говорят что FileInputStream заблокироваться то может, но при чтении не из файла. Может там и про файлы есть что-то, я не особо внимательно читал

fog

Уровень 18

13 апреля 2021, 17:07

Спасибо за ссылку!

АлександрРаботает в безработный

13 апреля 2021, 16:24

вот же ответ

or 0 when end of stream is detected.

available() лишь проверяет наличие данных и не блокирует поток выполнения при отсутствии данных

fog

Уровень 18

13 апреля 2021, 18:18

По сути вопрос и заключался в том, может ли переопределённый в классе FileInputStream метод available() возвратить нуль, при отсутствии доступных без блокировки данных, но до достижения конца файла (или того, что скрывается за соответствующим файловым дескриптором).

АлександрРаботает в безработный

14 апреля 2021, 00:46

возвратить нуль, при отсутствии доступных без блокировки данных,
но до достижения конца файла (или того, что скрывается за
соответствующим файловым дескриптором).

сам вопрос маленько поставлен не корректно

при отсутствии доступных

как такое возможно быть доступными и в то же время отсутствовать. available() если файл существует, возвращает примерное количество доступных для чтения байтов, пока не достигнет конца файла , а если произойдёт какой то форс-мажор (обрыв связи, сбой файловой системы, вирус и тд) это уже другое дело и available() не заблокирует поток, потому что он не читает данные , а только проверяет , если ещё байты в файле, а read() заблокирует.

fog

Уровень 18

14 апреля 2021, 09:01

Я не совсем корректно выразился, я имел в виду "при отсутствии доступных, без блокировки чтения, данных". "как такое возможно быть доступными и в то же время отсутствовать. available() если файл существует, возвращает примерное количество доступных для чтения байтов, пока не достигнет конца файла" Я уже нашёл пример "файлов" (см. мой комментарий выше), при обращении к которым, данные стабильно считываются, но метод available(), так же стабильно возвращает значение 0, при отсутствии каких-либо форс-мажоров.

АлександрРаботает в безработный

14 апреля 2021, 09:46

стабильно считываются, но метод available(), так же стабильно возвращает значение 0, при

отсутствии каких-либо форс-мажоров.

фоорс мажор здесь не при чём, просто пока файл считывается он для available() не доступен , так как read() блокурует его(файл).

fog

Уровень 18

14 апреля 2021, 10:57

Вы код в моём комменте смотрели? Там метод available() вызывается до обращения к методу read(). Не говоря уже о том, что метод read() синхронный, и в одном потоке, никак не возможно вызвать available() до завершения работы ранее вызванного read().

АлександрРаботает в безработный

14 апреля 2021, 12:28

Его сразу не было , а потом уже он был не виден, прочитал статью и мне не понятно

System.out.println("The value " + value + " was read from the file.");

тоже 0 или нет?

fog

Уровень 18

14 апреля 2021, 14:38

При чтении из /dev/null - да. Но, при чтении из /dev/random или /dev/urandom, в переменную value каждый раз считывается значение случайного байта, которое, в одном из 256 случаев, может оказаться нулём. А вот вызов метода available() при работе с этими файлами, всегда возвращает 0.

АлександрРаботает в безработный

14 апреля 2021, 14:51

Интересно , а если использовать FileReader , что будет возвращать метод ready()

АлександрРаботает в безработный

14 апреля 2021, 15:18

А вот вызов метода available() при работе с этими файлами, всегда возвращает 0.

может available() возвращает 0 , потому ,что пытается определить размер, а он не постоянен , как я понял. Вот интересная статья

fog

Уровень 18

14 апреля 2021, 17:22

Проверил в jshell, результаты следующие: Размер /dev/random получаемый с помощью класса File, всегда равен нулю. Метод ready() класса FileReader, так же как и одноимённый метод его базового класса, InputStreamReader, до первого чтения, возвращает значение false, а после первого чтения, всегда возвращает true, хотя метод available() нижележащего объекта класса FileInputStream, продолжает возвращать значение 0. Вероятно это происходит потому, что и FileReader, и InputStreamReader буферезируют операции чтения. Неясно, возвратит ли снова метод ready(), значение false, когда буфер будет опустошён. Так как до первого чтения, и соответственно заполнения буфера, возвращалось значение false, я пологаю это произойдёт и при опустошении буфера, до его следующего заполнения.

АлександрРаботает в безработный

15 апреля 2021, 01:30

Вот нашёл ещё статью и вот вырезка из неё

Использование catдля чтения /dev/urandomявляется
плохой идеей, потому что он будет пытаться читать /dev/urandom  до
 конца - но это не конец.

может поэтому available() возвращает 0 потому ,что тоже пытается прочитать до конца. Провёл такой эксперемент - попробовал копировать файл больше 2 гигов , хотелось узнать , что он выдаст , ведь размер файла больше ,чем тип int. вот фрагмент кода

{
      System.out.println("available = " + inputStream.available());
      int size = 1024;
      byte[] buffer = new byte[size];
      while (inputStream.available() > 0) {
        System.out.println("available = " + inputStream.available());
        int read = inputStream.read(buffer);
        outputStream.write(buffer, 0, read);
      }
    } catch (Exception e) {

думал выдаст ошибку или 0, оказалось всё банально просто , он выдал максимальное значение типа int 2147483647 и затем в цикле выводилось это значение , пока по мере копирования не стало уменьшаться.