IO 스트림에서 채널 래퍼 있습니까?

Question

SocketChannel, FileChannel 등의 클래스를 보면서 개념적 차이를 명확하게 구분하고 싶습니다. Socket 및 파일 I/O 스트림과 비교

알다시피, I/O 스트림은 순차적으로 액세스해야합니다. 즉, I/O 스트림은 읽기 및 쓰기가 가능한 바이트 시퀀스입니다. Buffered Stream을 사용하여 I/O의 효율성을 높일 수도 있습니다.

그래서 Streams와 비교하여 "채널"은 전혀 새로운 개념입니까, 아니면 Streams의 래퍼입니까?

예, "스트림이 일련의 바이트입니다."그렇다면 두 채널이 다른 경우 해당 의미로 채널이 무엇입니까?

Answer 1

아니요. 채널은 스트림 주위에 래퍼가 아닙니다 (명시 적으로 스트림을 Channels.newChannel(InputStream) 또는 Channels.newChannel(OutputStream)을 통해 래핑하지 않는 한) 완전히 "새로운 개념"은 아닙니다.

특정 유형에 따라 채널은 계속해서 순차적으로 읽거나 쓸 수있는 일련의 바이트를 나타냅니다. Channels 클래스의 팩토리 메소드를 통해 이러한 API간에 변환 할 수 있다는 사실은 관계가 있음을 보여줍니다.

그러나 NIO API는 호환 가능한 방식으로 이전 스트림 클래스를 리팩터링하여 수정할 수없는 특정 디자인 문제를 해결합니다. 예 : 기본 유형은 이제 인터페이스이므로 여러 채널 유형 (예 : ReadableByteChannel 및 WritableByteChannel)을 동시에 구현할 수 있습니다. 또한 단일 바이트를 읽는 방법은 없습니다. "BufferedStream을 사용하여 효율성을 높일 수 있습니다"라는 신화를 제거하는 좋은 방법입니다. 불충분 한 버퍼 크기로 인해 I/O 성능 병목 현상이 발생하는 경우 스트림이나 채널을 다른 버퍼로 래핑하는 대신 버퍼간에 모든 데이터를 강제로 복사하는 대신 더 큰 버퍼를 제공하여 문제를 해결하십시오. 따라서 BufferedChannel이 없습니다.

FileChannel과 같은 특정 구현은 순차 액세스 외에도 기본 리소스에 대한 임의 액세스를 허용하는 추가 방법을 제공합니다. 그렇게하면 RandomAccessFile/InputStream/OutputStream 관계와 같이 완전히 다른 API를 처리하는 대신 균일 한 인터페이스를 사용할 수 있습니다.

이전에 누락 된 많은 I/O 기능이 NIO 도입시 추가되었습니다. 그 중 일부는 문제없이 이전 클래스에 구현 될 수 있었지만 디자이너는 새로운 API를 사용하는 것을 분명히 좋아했습니다. 처음에는 디자인에서 이러한 기능을 고려할 수있었습니다.

그러나 일반적으로 채널은 스트림에 비해 완전히 새로운 개념이 아닙니다.