[F-Lab 챌린지 13일차] TIL : 프로젝트 기획 - 2 & NIO 맛보기

오늘 프로젝트 회의에서는 협업 관련된 컨벤션들을 정했다.

개발방식

• 회원 도메인은 페어프로그래밍한다.
• 나머지 도메인은 각자 개발 후 approve 먼저받은 pr을 머지한다.

Git Branch 전략

저희는 gitlab-flow에 저희가 추가로 설정한 dev 브랜치 종류(feat, refactor)를 추가하였습니다.

참고) https://techblog.woowahan.com/2553/

• 종류
  • main : 제품 출시 가능 브랜치
  • release : 이번 출시 버전을 준비하는 브랜치
  • dev : 다음 출시 버전을 개발하는 브랜치
    • feat : 새로운 기능 개발
    • refactor : 기존 개발 리팩토링
  • hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
• 예시
  • dev/feat/회원가입
  • dev/feat/로그인
    

Branch 네이밍 규칙

• {종류}/{issue-number}-{feature-name}
• 예시) feat/1/회원가입

커밋 컨벤션

<커밋 타입>[(옵션) scope]: <description>

[(옵션) body]

[(옵션) footer(s)]

// 예시

fix: prevent racing of requests
또는 fix(로그인): prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Refs: #123

• 커밋 타입
  • fix
    • 버그 수정일 경우
  • feat
    • 새로운 기능 추가인 경우
  • chore
    • 코드 수정 없이 설정 변경
  • docs
    • 문서 수정인 경우
  • refactor
    • 리팩토링

---

NIO 입출력 작업이 IO 보다 빠른 이유

결국 이해 못했습니다. 아래 정리된 내용은 인증안된 내용이니 패스하세요.

non-direct buffer

• JVM 이 관리하는 힙 메모리 공간을 이용하는 버퍼
• 버퍼 크기를 크게 잡을 수 없음

direct buffer

• 운영체제가 관리하는 메모리 공간을 이용하는 버퍼
• 운영체제가 허용하는 범위내에서 대용량 버퍼를 생성시킬 수 있음

---

1. Java I/O 를 사용하면 JVM 프로세스가 System call 로 입출력을 요청한다.

   read() 의 경우 받아온 데이터를 커널 영역의 버퍼에 저장하고,

   이를 복사해 JVM 이 접근할 수 있는 영역의 버퍼에 저장한다.

   복사 이유는 JVM이 커널 영역의 버퍼에 접근할 수 없어 복사를 하는 것인데, 이게 비효율적이다.

2. Java NIO 에서는 읽은 데이터를 무조건 buffer 에 저장하는데, IO 와 달리

   커널 영역에 저장된 버퍼에 바로 접근할 수 있다. 이것이 Direct Buffer 버퍼다.

   NIO의 Channel 이 JVM과 커널 영역의 Direct Buffer 와 파이프 역할을 한다.

   Scatter gather I/O 모델 형식으로 효율적인 I/O 처리를 지원한다. 여러개 버퍼에 데이터를 담을 수 있는데,

   이 버퍼들을 모아서 한 번에 처리하기 때문에 IO 보다 시스템 호출 횟수가 적다.