NIO 채널 과 버퍼

NIO 채널 과 버퍼
채널 과 버퍼 는 NIO 의 핵심 대상 으로 거의 모든 I/O 작업 에서 사용 해 야 한다.
AD：
  채널 과 버퍼 는 NIO 의 핵심 대상 으로 거의 모든 I/O 작업 에서 사용 해 야 한다.
채널 은 원 I/O 패키지 의 흐름 에 대한 시 뮬 레이 션 입 니 다.모든 목적지(또는 어디에서 왔 는 지)에 이 르 는 모든 데 이 터 는 채널 대상 을 통과 해 야 합 니 다.버 퍼 는 실질 적 으로 용기 의 대상 이다.한 채널 에 보 내 는 모든 대상 은 먼저 버퍼 에 넣 어야 합 니 다.마찬가지 로 채널 에서 읽 은 모든 데 이 터 는 버퍼 에 읽 어야 합 니 다.
이 절 에서 NIO 의 채널 과 버퍼 가 어떻게 작 동 하 는 지 알 게 될 것 입 니 다.
버퍼 가 무엇 입 니까?
Buffer 는 기록 하거나 방금 읽 은 데 이 터 를 포함 하 는 대상 입 니 다.NIO 에 Buffer 대상 을 추가 하면 새 라 이브 러 리 와 원 I/O 의 중요 한 차이 점 을 나 타 냈 다.스 트림 을 위 한 I/O 에서 데 이 터 를 직접 쓰 거나 스 트림 대상 에 직접 읽 습 니 다.
NIO 라 이브 러 리 에 서 는 모든 데 이 터 를 버퍼 로 처리 합 니 다.데 이 터 를 읽 을 때 버퍼 에 직접 읽 습 니 다.데 이 터 를 쓸 때 버퍼 에 기 록 됩 니 다.언제든지 NIO 의 데 이 터 를 방문 하면 버퍼 에 넣 습 니 다.
버퍼 는 실질 적 으로 하나의 배열 이다.보통 바이트 배열 이지 만 다른 종류의 배열 도 사용 할 수 있다.그러나 버퍼 는 하나의 배열 만 이 아니다.버퍼 는 데이터 에 대한 구조 적 접근 을 제공 하고 시스템 의 읽 기/쓰기 프로 세 스 를 추적 할 수 있 습 니 다.
버퍼 종류
가장 많이 사용 되 는 버퍼 종 류 는 ByteBuffer 입 니 다.ByteBuffer 는 바 텀 바이트 배열 에서 get/set 작업 을 할 수 있 습 니 다(즉,바이트 가 져 오기 와 설정).
ByteBuffer 는 NIO 에서 유일한 버퍼 형식 이 아 닙 니 다.사실 모든 기본 자바 형식 에는 버퍼 형식 이 있 습 니 다.

ByteBuffer
CharBuffer 
ShortBuffer 
IntBuffer 
LongBuffer 
FloatBuffer 
DoubleBuffer 

모든 Buffer 류 는 Buffer 인터페이스의 인 스 턴 스 입 니 다.ByteBuffer 를 제외 하고 모든 Buffer 류 는 똑 같은 조작 을 하 는데 그들 이 처리 하 는 데이터 형식 이 다 를 뿐이다.대부분의 표준 I/O 작업 은 ByteBuffer 를 사용 하기 때문에 모든 공 유 된 버퍼 작업 과 특유 의 조작 을 가지 고 있 습 니 다.
이제 UseFloat Buffer.java 를 실행 하 는 데 시간 이 좀 걸 릴 수 있 습 니 다.형식 화 된 버퍼 의 응용 예 를 포함 하고 있 습 니 다.
통로 가 무엇 입 니까?
Channel 은 데 이 터 를 읽 고 기록 할 수 있 는 대상 입 니 다.NIO 를 원래 의 I/O 와 비교 하면 통로 가 마치 흐름 과 같다.
앞에서 언급 한 바 와 같이 모든 데 이 터 는 버 퍼 대상 을 통 해 처리 된다.채널 에 바 이 트 를 직접 쓰 지 않 을 것 입 니 다.반대로 하나 이상 의 바 이 트 를 포함 하 는 버퍼 에 데 이 터 를 쓰 는 것 입 니 다.마찬가지 로 채널 에서 바 이 트 를 직접 읽 지 않 고 채널 에서 버퍼 를 읽 고 버퍼 에서 이 바 이 트 를 가 져 옵 니 다.
채널 형식
통로 와 흐름 의 차이 점 은 통로 가 양 방향 이라는 데 있다.스 트림 은 한 방향 으로 만 이동 합 니 다.(하나의 스 트림 은 InputStream 또는 OutputStream 의 하위 클래스 여야 합 니 다)채널 은 읽 기,쓰기 또는 읽 기,쓰기 에 사용 할 수 있 습 니 다.
양 방향 이기 때문에 통 로 는 흐름 보다 바 텀 운영 체제 의 실제 상황 을 잘 나 타 낼 수 있다.특히 유 닉 스 모델 에 서 는 바 텀 운영 체제 채널 이 양 방향 이다.
원본 링크:http://www.cnblogs.com/sunwei2012/archive/2010/07/06/1772435.html