FileDescriptor.in против System.in
В Java мы можем использовать класс Scanner для ввода данных, но он не так эффективен, как BufferedReader в пакете ввода-вывода. При инициализации объекта класса 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
Похоже, ваш вопрос "System.in хорош по сравнению с FileDescriptor.in?"
Ответы:
- Это разные.
System.inможно заменить наSystem.setIn, ноFileDescriptor.inвсегда указывает на один и тот же источник ввода-вывода (пока вы запускаете программу, если вы не используете собственный код), поэтому вы менее гибки, если используетеFileDescriptor.in. - С настройками по умолчанию при запуске виртуальной машины производительность такая же, если вы помните, что
System.inбуферизуется, поэтому любая альтернатива также должна буферизоваться.
Доказательство пункта 2 находится в исходном коде класса System:
FileInputStream fdIn = new FileInputStream(FileDescriptor.in);
// ...
setIn0(new BufferedInputStream(fdIn));
Стандартный поток, который вы получаете от System.in, - это FileInputStream, который читает с FileDescriptor.in, но есть BufferedInputStream, обернутый вокруг него по соображениям производительности (это улучшает производительность небольших чтений).