0329 - 0404

0329 - log

SLF4J

Simple Logging Facade for Java 의 약자로 logging framework들을 추상화 해 놓은 것. Facade Pattern을 적용한 logging framework이다.

Logback

• Spring Boot는 logback이 기본으로 설정, 별도로 라이브러리를 추가 하지 않아도 된다.

  • spring-boot-starter-web 안에 spring-boot-starter-logging 구현체 존재.

• logback-spring.xml

<?xmlversion="1.0"encoding="UTF-8"?>
<configuration>

<!--프로퍼티-->
<!--<propertyname="LOGS_PATH"value="./logs"/>-->

<appendername="CONSOLE"class="ch.qos.logback.core.ConsoleAppender">
<layoutclass="ch.qos.logback.classic.PatternLayout">
<pattern>%highlight(%-5p):[%d{yyyy-MM-ddHH:mm:ss:mmm}]%cyan(%c)-%m%n{2,CALLER_DISPLAY_EVAL}</pattern>
</layout>
</appender>

<appendername="SAMPLE"class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>[%d{yyyy-MM-ddHH:mm:ss}:%-3relative][%thread]%-5level%logger{35}-%msg%n</pattern>
</encoder>
</appender>

<appendername="COM_FILE"class="ch.qos.logback.core.rolling.RollingFileAppender">
<filterclass="ch.qos.logback.classic.filter.ThresholdFilter">
<level>INFO</level>
</filter>
<prudent>true</prudent>
<rollingPolicyclass="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${ROUTER_HOME}/log/router_log.%d{yyyy-MM-dd}.log</fileNamePattern>
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%-5p:[%d{yyyy-MM-ddHH:mm:ss:mmm}]%c-%m%n</pattern>
</encoder>
</appender>

<loggername="com.ese"additivity="false"level="INFO">
<appender-refref="CONSOLE"/>
<appender-refref="COM_FILE"/>
</logger>

<!--RootLogger-->
<rootlevel="INFO">
<appender-refref="CONSOLE"/>
</root>
</configuration>

• appender : log의 형태를 설정
• logger : 설정한 appender를 참조하여 package와 level을 설정
• property : 프로퍼티를 설정

0330 - Maven Wrapper

구성

• https://github.com/takari/takari-maven-plugin
  Maven wrapper plugin 사용

• intellij 기준 [ ctrl + ctrl ]
  mvn (모듈명) -N io.takari:maven:wrapper 실행
  => .mvn mvnw, mvnw.cmd 생성

mvnw / mvwn,cmd

• mvnw : Maven 대신에 사용되는 실행 가능한 unix shell script.
• mvwn.cmd : mvnw 의 윈도우 배치 버전 shell script.

.mvn

• MavenWrapperDownloader.java : 자바클래스 파일인 이파일을 컴파일링하여 메이븐 다운로드
• maven-wrapper.jar : wrappper shell scripts 로 부터 maven 을 실행하고, 다운로드 하는데 사용
• maven-wrapper.properties : Maven 이 존재하지 않는 경우 다운로드하기 위한 URL 을 명시하기 위해서 사용

Maven Wrapper 실행하기

• Maven/target Clean 및 build
  • ./mvnw clean package
• Maven 으로 Spring boot 를 백그라운드로 실행
  • ./mvnw spring-boot:run &
• mvnw 로 설치된 maven 배포 경로
  • ~/.m2/wrapper/dists

0331 - GitHub 저장소(repository) 미러링

미러링이란 commit log를 유지하며 clone

저장소 미러링

1. 복사하고자하는 저장소의 bare clone 생성

git clone --bare {복사하고자하는 저장소의 git 주소}

2. 새로운 저장소로 mirror-push

cd {복사하고자하는 저장소의 git 주소}
git push --mirror {붙여놓을저장소의 git 주소}

3. 1번에서 생성된 저장소 삭제

100MB를 넘어가는 파일을 가진 저장소 미러링

1. git lfs와 BFG Repo Cleaner 설치
2. 복사하고자 하는 저장소의 bare clone 생성

git clone --mirror {복사하고자하는저장소의 git 주소}

3. commit history에서 large file을 찾아 트랙킹

git filter-branch --tree-filter 'git lfs track "*.{zip,jar}"' -- --all

4. BFG를 이용하여 해당 파일들을 git lfs로 변경

java -jar ~/usr/bfg-repo-cleaner/bfg-1.13.0.jar --convert-to-git-lfs '*.zip'
java -jar ~/usr/bfg-repo-cleaner/bfg-1.13.0.jar --convert-to-git-lfs '*.jar'

5. 새로운 저장소로 mirror-push

cd {복사하고자하는저장소의 git 주소}
git push --mirror {붙여놓을저장소의 git wnth}

6. 1번에서 생성된 저장소 삭제

0401 - 웹 애플리케이션 정리

웹 애플리케이션이란 HTTP 요청을 받고 HTTP 응답을 만드는 코드를 작성한다는것
이점을 인지하고 개발하는게 중요 => 웹 기술 빠르게 파악가능

HTTP 요청

• URI
• METHOD
• HEADER
• BODY

스프링은 HTTP 요청을 통해 두가지 작업을 한다.

1. 요청을 처리할 컨트롤러를 찾는 작업 - Mapping
2. 컨트롤러 메소드에 요청 정보를 어떤 식으로 전달할까를 결정하는 작업

@RequestMapping("/hello")
=> HTTP 요청중 URI 부분으로 매핑  
=> 보통 BODY는 매핑에 사용되지않고, 나머지 구성요소로함.

매핑에서 컨트롤러 메소드까지 결정하면 그 다음은 파라미터에 어떻게 HTTP 요청을 가공해서 넘겨줄 것인가를 정하는 것.
(바인딩하는 방법은 관례적으로 30가지가 존재)

HTTP 응답

HTTP 응답은 크게

• 상태 코드
• 헤더
• 바디

가장먼저 상태코드를 넣고 헤더 요소 중 content type에 따라 바디에 html을 넣을지, json을 넣을지, binary를 인코딩해서 넣을지 등등을 결정.

*** 결론은 웹 개발에서 가장 중요시 해야하는 것은 '요청과 응답이 어떻게 다뤄지고 만들어지는가' 이다.

---

정리

0402 - 데드락(DeadLock)

프로세스가 자원을 얻지 못해서 다음 처리를 하지 못하는 상태
'교착 상태'라고도 부름
시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할 때 발생

데드락이 일어나는 경우

프로세스 1과 2가 자원1,2를 모두 얻어야 한다고 가정했을때

t1 : 프로세스 1이 자원1을 얻음 / 프로세스2가 자원 2를 얻음
t2 : 프로세스1은 자원2를 기다림 / 프로세스2는 자원1을 기다림

현재 서로 원하는 자원이 상대방에 할당되어 있어서 두 프로세스는 무한정 wait 상태에 빠짐
-> 이게 DeadLock

[주로 발생하는 경우]

• 멀티 프로그래밍 환경에서 한정된 자원을 얻기 위해 서로 경쟁하는 상황 발생
• 한 프로세스가 자원을 요쳥했을 때, 동시에 그 자원을 사용할 수 없는 상황이 발생할 수 있음. 이때 프로세스는 대기 상태로 들어감
• 대기상태로 들어간 프로세스들이 실행 상태로 변경될 수 없을 때 '교착 상태' 발생

데드락 발생 조건

4가지 모두 성립해야 데드락 발생(하나라도 성립하지 않으면 데드락 문제 해결 가능)

1. 상호 배제(Mutual exclusion)

• 자원은 한 프로세스만 사용할 수 있음

2. 점유 대기(Hold and wait)

• 최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용하고 있는 자원을 추가로 점유하기 위해 대기하는 프로세스가 존재해야 함

3. 비선점(No preemption)

• 다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 빼앗을 수 없음

4. 순환 대기(Circular wait)

• 프로세스 집합에서 순환 형태로 자원을 대기하고 있어야 함

데드락 처리

• 교착 상태를 예방 & 회피

1. 예방(prevention)
   교착 상태 발생 조건 중 하나를 제거하면서 해결한다 (자원 낭비 엄청 심함)
   • 상호배제 부정 : 여러 프로세스가 공유 자원 사용
   • 점유대기 부정 : 프로세스 실행전 모든 자원을 할당
   • 비선점 부정 : 자원 점유 중인 프로세스가 다른 자원을 요구할 때 가진 자원 반납
   • 순환대기 부정 : 자원에 고유번호 할당 후 순서대로 자원 요구
2. 회피(avoidance)
   교착 상태 발생 시 피해나가는 방법
   은행원 알고리즘(Banker's Algorithm)
   • 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는데서 유래함
   • 프로세스가 자원을 요구할 때, 시스템은 자원을 할당한 후에도 안정 상태로 남아있게 되는지 사전에 검사하여 교착상태 회피
   • 안정 상태면 자원 할당, 아니면 다른 프로세스들이 자원 해지까지 대기

• 교착 상태를 탐지 & 회복
  교착 상태가 되도록 허용한 다음 회복시키는 방법

1. 탐지(Detection)
   자원 할당 그래프를 통해 교착 상태를 탐지함
   자원 요청 시, 탐지 알고리즘을 실행시켜 그에 대한 오버헤드 발생함
2. 회복(Recovery)
   교착 상태 일으킨 프로세스를 종료하거나, 할당된 자원을 해제시켜 회복시키는 방법
   • 프로세스 종료 방법
     • 교착 상태의 프로세스를 모두 중지
     • 교착 상태가 제거될 때까지 하나씩 프로세스 중지
   • 자원 선점 방법
     • 교착 상태의 프로세스가 점유하고 있는 자원을 선점해 다른 프로세스에게 할당 (해당 프로세스 일시정지 시킴)
     • 우선 순위가 낮은 프로세스나 수행 횟수가 적은 프로세스 위주로 프로세스 자원 선점

0403 - Object 클래스 wait, notify, notifyAll

Java 최상위 클래스 = Object 클래스

Object Class가 갖고 있는 메서드

• toString()
• hashCode()
• wait()
  갖고 있던 고유 lock 해제, Thread를 잠들게 함
• notify()
  잠들던 Thread 중 임의의 하나를 깨움.
• notifyAll() 잠들어 있던 Thread를 모두 깨움.

wait, notify, notifyAll : 호출하는 스레드가 반드시 고유 락을 갖고 있어야함.

• Synchronized 블록 내에서 실행되어야 함.
• 그 블록 안에서 호출하는 경우 IllegalMonitorStateException 발생.