아장아장 프로그래밍2

https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom

JVM은 대략 네 섹션으로 메모리를 나눌 수 있다. 

스택

힙

메소드

텍스트

힙과 스택은 서로 마주보고 쌓임. 

그리고 힙을 다시 확대해서 볼 수 있다. 

그 안에 young(eden) old permanent가 존재하고, 나머지는 GC를 진행하는 방법에 의거해서 힙을 사용한다. GC관련된 좋은 내용(http://d2.naver.com/helloworld/1329)

로그가 이렇게나 개떡같이 구구절절하고 길 수도 있구나 하고 깨달았다. 간결하고, 정확한 정보를 전달해야 한다. ㅠㅠㅠ

지금까지 rm -rf로 욕봤다-는 이야기 전설처럼 들어만 봤지 직접 겪은 일은 처음이다. 

평소에는 내 작업 폴더에서 작업하고 완료 되면 폴더를 만들어서 분류해서 넣었는데....오늘따라 다행히도 성실히 폴더를 만들고 그 안에서 작업을 한게 다행이었다.

짜 놓은 펄 코드 중에(이미 날아가신) >>로 파일을 덧붙여써서 결과 파일이 테스트 하면서 지저분해졌길래 그냥 그 결과로 만드는  파일 명인 result..로 시작하는 여러개의 파일을 다 날려버리고 새로 펄 파일을 실행시켜서 파일을 쓰고 싶었다.  

rm -rf result* 를 하려는게 목적이었지만...

rm -rf result * 를 실행해서 짜던 코드,  파싱해서 저장해놓은 user list, 다 날아가심...

진짜 이런 경험 처음이다. 와우....무섭다 무섭다 말만 들었지.ㅋㅋㅋㅋㅋㅋㅋ조심해야겠다. 

출처: https://blog.outsider.ne.kr/702

시키는대로 하면된다. tmux를 사용하지 않는 가장 큰 이유였는데 간단하게 해결해서 기쁨. 

-  .tmux.conf 는 존재하지 않아서 임의로 그냥 생성했다. 잘 동작한다. 

https://ko.wikipedia.org/wiki/%EC%A0%95%EA%B7%9C_%ED%91%9C%ED%98%84%EC%8B%9D

일단 기초적인 정리는 위키피디아에 되어있다. 그러나! 나처럼 기초가 1도 없는 상황에서는 예시를 보면서 확인하는게 훨씬 쉽다. 

http://regexr.com/

https://regex101.com/

이 두 사이트에서 실제 예시를 두고 내가 만드는 정규표현식이 적절한지 알 수 있기 때문에 여기를 보면 좋다. 

지금까지 intelliJ에서 live template을 세개 만들어봤는데, 늘 쉽지가 않아서 정리해둔다. 

1. 반드시 적용가능한 언어를 선택하지 않으면 live template을 생성할 수 없다. 

처음 로거를 템플릿으로 등록하려고 했을 때 문제가 되었던 것이 이 부분이다. 

- 좌측 하단의 빨간 박스에서 적용할 언어를 선택해야 한다. 

2. 우측 빨간 박스 안에 있는 체크 박스 중 Use static import if possible 에 체크한다.

- 늘 그런 것은 아니지만 import를 의도할 때 static import를 필요로 할 때가 있다. 

- 가능한 경우 static import를 한다는 의미이기 때문에 가능하면 체크해두면 임포트가 안돼서 슬퍼할 일을 예방 가능하다.

- 마찬가지로 나는 아예 체크박스를 이제 다 체크하기로 했다. 별 문제 의식 없이 체크해도 아직까지는 큰 문제가 발생하지 않았다. 

live template 예시는 이하에 업로드 한다. 

1. logger

2. junit

3. assertj

github 에서 희한하게 브랜치를 생성할 수 있는 방법을 찾았다. 

find  or create branch;;

주소창에 치고 있다고 생각했는데 갑자기 화면 리프레쉬가 된 것 같아서 살펴보니 갑자기 리모트 브랜치를 땄음. 그런데 어떻게 삭제하는지를 몰라서 슬퍼하고 있었다. 로컬에는 리모트의 브랜치가 없기 때문에 풀을 한번 받아서 리프레쉬를 한 후에

git pull origin 

git push origin --delete branchname 

하면 삭제할 수 있다. 풀을 받지 않으면 원격지에서 만든 브랜치를 확인할 수 없기 때문에...풀을 먼저 받아야 한다. 

네티 6장

자바 NIO 바이트 버퍼: 바이트 데이터를 저장하고 읽는 저장소, 배열을 가지고 읽쓰를 추상화한 메서드를 가지고 있음. 

종류

- ByteBuffer

- CharBuffer

- InteBuffer

- ShortBuffer

- LongBuffer

- FloatBuffer

- DoubleBuffer

 속성  

* capacity: 버퍼에 저장할 수 있는 데이터의 최대 크기. 변경 불가능-

* position : 읽.쓰가 작업 중인 위치. 버퍼 객체가 생성될 때 0으로 초기화되고 get/put 호출되면 증가함. 당연히 capacity와 limit 사이의 값

- flip 메소드를 사용한 후 position이 0이 된다. 

* limit : 버퍼에 저장할 수 있는 공간의 최대치 . capacity보다 작음. (공간의 최대치라고 생각했는데 포인터처럼 11을 가리키고 있는 예시가 있다. 정확한 의미를 모르겠다.)

- flip메소드를 사용한 이후, position값으로 이동한다. 즉, 마지막으로 데이터가 기록된 위치가 됨

** flip 메소드를 사용해서 읽-> 쓰 / 쓰-> 읽 으로 작업 전환이 가능함. 

*  생성

- 팩토리 메소드를 사용해서 생성

- allocate: 힙에 바이트 버퍼를 생성.

- 힙 버퍼: 생성은 빠르지만 읽쓰가 느리다

- allocateDirect: 운영체제의 커널 영역에 생성(다이렉트 버퍼)

- 다이렉트 버퍼: 생성시간은 길지만 빠르다

- wrap: 입력된 바이트 배열을 사용해서 바이트 버퍼를 생성. (힙 버퍼)

<네티 바이트 버퍼>

- 각각의 배열 type에 대한 read~(type) / write~(type)을 지원. 

- readerIndex:

- writeIndex: 

읽쓰가 인덱스를 각각 가지고 잇어서 flip이 필요하지 않음. 

- capacity

* 네티 바이트 버퍼는 풀을 제공한다. 

- ByteBufAllocator 인터페이스를 사용, 하위 추상 구현체를 이용해서 바이트 버퍼를 생성한다. 

* 풀링을 사용할지 

* 힙버퍼를 쓸지 다이렉트 버퍼를 쓸지 

선택할 수 있다. 그래서 2^2 = 4가지 바이트 버퍼 속성이 나온다. 

각각의 속성에 따라 바이트 버퍼를 생성할 때 사용하는 메소드 종류가 다르다. 

* 표 정리 

- 바이트 버퍼의 크기를 할당하지 않으면 256바이트가 생성된다. 

- 네티 바이트 버퍼의 크기는 줄였다 늘렸다 할 수 있다. buffer.capacity(int )로 크기를 조정. 

<바이트 버퍼 풀링>

장점

- 버퍼를 할당 해제 하면서 일어나는 GC감소

* release method

- 해당 버퍼에 대한 참조를 --;

*retain method

- 해당 버퍼에 대한 참조를 ++

<음수 입력시 >

- 음수 입력이 들어오면 데이터를 큰 데이터 타입으로 변환해서 리턴한다. 

<빅엔디안 사용>

3장. 

부트 스트랩: 네티로 작성한 네트워크 애플리케이션의 동작 방식과 환경을 설정하는 도우미 클래스

- 이벤트 루프

- 채널의 전송모드

- 채널 파이프라인

지원하는 설정

- 전송계층(소켓 모드 및 I/O 종류)

- 이벤트 루프(단일 스레드, 다중 스레드)

- 채널 파이프라인 설정

- 소켓 주소와 포트

- 소켓 옵션

부트스트랩의 종류

- ServerBootstrap: for server- 소켓 연결을 대기

- BootStrap: client- 소켓 연결을 요청

서로 API구조는 같지만 소켓 연결에 대한 입장의 차이가 있음.

* 부트스트랩은 빌더 패턴을 사용하면 효율적으로 사용할 수 있음. 

- 설정의 내용이 추가될 때마다 생성자를 추가할 필요가 없기 때문. 

* 부트스트랩에서 사용할 부모 이벤트 루프 그룹과 자식 이벤트 루프 그룹의 수를 인자로 결정할 수 있다. 

- 그룹에서 동작할 스레드 수를 결정하지 않을 경우 하드웨어가 가지고 있는 CPU*2 배의 스레드를 사용한다. 

* 부트스트랩에서 사용할 이벤트루프 그룹의 종류는 생성할 때    NIO/ OIO/ EPOLL  eventgroup 클래스로 생성을 하느냐에 달려있다. 

- NIO:  넌블락

- OIO: 블락

- EPOLL : 이폴 지원 

---

ServerBootstrap의 API

* ServerBootstrap.class - group(eventLoopGroup group);

- 이벤트 루프 그룹을 BootStrap의 변수에 설정하고 Bootstrap 객체 자신을 리턴한다.

- override 한 group(group)의 기능 내에서 사용하는 group(group, group) 기능은 부모와 자식 이벤트 루프를 구분해서 사용할 수 있게 한다. 

* Channel()

- 소켓의 입출력 모드를 설정

- 여~러가지 종류가 있다. 

* ChannelFactory

- 소켓의 입출력 모드를 설정

- ChannelFactory 인터페이스를 구현가능

* Handler

- 이벤트를 처리하는 녀석. 

- 빌더 패턴으로 핸들러 객체를 설정해서 넣으면 이벤트가 발생했을 때 실행될 핸들러를 설정할 수 있다. 

- ChannelHandler 인터페이스 구현체를 인자로 받는다

* ChildHandler

- 클라이언트 소켓 채널로 송수신 되는 데이터를 가공하는 데이터 핸들러 설정할 수 있다.

- 빌더 패턴으로 Handler와 같이 ChannelHandler 인터페이스 구현체를 인자로 받는다

- 예를 들어 Handler 대신 ChildHandler를 사용해서 로그핸들러를 인자로 설정하면 클라이언트에서 발생한 이벤트까지 로그로 찍을 수 있다.(로그 핸들러가 아니면서 양쪽의 이벤트를 모두 필요로 하는 경우는 어떤 것이 있을지 잘 모르겠다.)

* option

- 서버 소켓 채널의 소켓 옵션을 설정하는 API

- 소켓 옵션: 소켓의 동작 방식을 지정하는 거엇.

- 주요 소켓 옵션이 있다~

** ChannelOption.TCP_NODELAY

- 네이글 알고리즘의 비활성화 여부 설정

- 네이글 알고리즘: 가능하면 데이터를 나누어 보내지 말고 한꺼번에 보내라는 원칙을 가진 알고리즘.

- 네트워크 상태가 좋지 않고 대역폭이 좁을 때 헤더로 인한 불필요한 오버헤드를 줄이고 데이터를 모아서 보내라.

- 작은 크기의 데이터는 송신버퍼에서 적당히 모아서 보낸다.

- 이전에 보내내 패킷의 ACK를 받아야 다음 패킷을 전송한다. 

- 이 옵션은 ACK를 받을 떄까지 다음 패킷을 전송하지 않기 때문에 빠른 속도가 필요할 때는 문제가 된다. 

** ChannelOption.SO_REUSEADDR

- TCP 통신을 종료할 때 클라이언트에서 마지막으로 FIN을 보내고 나서 발생하는 타임아웃으로 인해 어플리케이션 서버가 재시작 하려고 하면 bind 실패로 망함.

- 이 옵션을 켜주면 TIME_WAIT에 걸려있더라도 bind 가능함

** ChannelOption.SO_BACKLOG

- 동시에 수용 가능한 클라이언트 연결 요청 개수를 서버 소켓에 설정 가능한 옵션

- 그런데 이 개수가 서버 소켓이 소화가능한 동시 연결수와 동일하지 않다. 

- SYN-ACK상태의 연결요청을 보관하는 큐의 크기를 설정하는 것이 바로 SO_BACKLOG

- 너무 크게 잡으면 연결이 폭주할 때 연결 대기 시간이 길어지는 단점이 있음. 

* childOption

- 클라이언트 소켓 채널에 소켓 옵션을 설정.

**SO_LINGER  

- 소켓 종료 시, close함수가 실행되었는데 아직 커널 버퍼에 전송되지 않은 데이터가 남아있을 경우 이를 처리하는 방법을 지정하는 옵션. 

- 이 옵션의 사용 여부/ 타임아웃 값 설정 가능

- FALSE가 디폴~ㅌ

- 이 옵션을 사용하고 타임아웃값을 0으로 주면 마지막 남은 데이터를 모두 전송하고 연결을 끊어버림. TIMEWAIT 발생하지 않는 장점이 있음. 

---

Bootstrap API

- ServerBootstrap 과 Bootstrap API는 대체로 비슷하다. 

- 그러나 부모-자식 관계에 대한 API 는 없다.(option- childOption)

* group 

- 이벤트 루프 객체를 설정.

- 하나의 이벤트 루프 객체만 설정 가능하다. (부모-자식 설정 불가하기 때문)

- AbstractBootstrap의 그룹 메소드를 고대로 사용.

* channel

- 클라이언트 소켓 채널의 입출력 모드를 설정.

- 요러저러한 클래스 목록이 있다. p94

* channelFactory

- ServerBootstrap의 그것과 같은 역할.

* handler

- 클라이언트 소켓 채널에서 발생하는 이벤트를 수신하여 처리. 

- ChannelInitializer를 구현해서 사용

- 

* option

- 클라이언트의 소켓 설정을 옵션 설정.