FileDescriptor.in v / s System.in - PullRequest
Новая
       67

FileDescriptor.in v / s System.in

0 голосов
/ 01 мая 2018

В Java мы можем использовать класс Scanner для получения ввода, но он не так эффективен, как BufferedReader пакета IO. При инициализации объекта класса Scanner или объекта класса BufferedReader мы используем InputStream "System.in". Есть System.in хорошо по сравнению с FileDescriptor.in?

Например, если я использую System.in с BufferedReader:

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

И используя FileDescriptor.in:

BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(FileDescriptor.in), "ASCII"));

То же самое происходит при печати:

Использование System.out OutputStream:

System.out.println("Hello World!");

Использование FileDescriptor.out с BufferedWriter:

BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(FileDescriptor.out),"ASCII"), 512);

1 Ответ

0 голосов
/ 01 мая 2018

Похоже, ваш вопрос "Является ли System.in хорошим по сравнению с FileDescriptor.in?"

Ответы:

  1. Они отличаются . System.in можно изменить с помощью System.setIn, но FileDescriptor.in всегда указывает на один и тот же источник ввода-вывода (пока вы запускаете программу, если вы не используете собственный код), поэтому вы менее гибки, если используете FileDescriptor.in.
  2. При настройках по умолчанию при запуске виртуальной машины производительность остается той же, если учесть, что System.in буферизован, поэтому любая альтернатива также должна быть буферизована.

Доказательство пункта 2 содержится в исходном коде класса System: 

    FileInputStream fdIn = new FileInputStream(FileDescriptor.in);
    // ...
    setIn0(new BufferedInputStream(fdIn));

Стандартный поток, который вы получаете от System.in, - это FileInputStream, который читает из FileDescriptor.in, но есть BufferedInputStream, обернутый вокруг него по соображениям производительности (это улучшает производительность небольших операций чтения).

...