이미지 디렉토리 위치 변경

eunjee · Jun 20, 2019 · 8e94803 · 8e94803
1 parent e49397c
commit 8e94803
Show file tree

Hide file tree

Showing 63 changed files with 64 additions and 40 deletions.
diff --git a/JAVA/thread.md b/JAVA/thread.md
@@ -42,7 +42,7 @@
   * 메인 스레드(메인 스레드는 JVM이 생성)는 작업 스레드를 만들어서 병렬로 코드들을 실행 할 수 있다.
 
 ## 멀티 스레드, 싱글 스레드
-![](/draw/java-thread-single-multy.png)
+![](/assets/java-thread-single-multy.png)
 
 
 * 싱글 스레드 : 메인 스레드가 종료하면 프로세스도 종료된다.
@@ -52,7 +52,7 @@
 # 스레드 우선 순위
 
 ## 동시성과 병렬성
-![](/draw/concurrency-Parallelism.png)
+![](/assets/concurrency-Parallelism.png)
 
 * 동시성(concurrency)
   * 멀티 작업을 위해 하나의 코드에서 멀티 스레드가 번갈아 가며 실행하는 성질
@@ -63,7 +63,7 @@
 
 ## 스레드 스케쥴링
 
-![](/draw/thead-shduler.png)
+![](/assets/thead-shduler.png)
 
 * 스레드의 개수가 코어의 수보다 많은 경우
   * 스레드를 어떤 순서로 동시성으로 실행할것인가를 결정, **스레드 스케쥴링**
@@ -88,7 +88,7 @@
 
 ## 공유 객체를 사용할 때 중의 할 점
 
-![](/draw/thread-synchronization.png)
+![](/assets/thread-synchronization.png)
 1. User 1 스레드 : 메모리에 100을 Calculator 객체에 저장
 2. User 2 스레드 : 메모리에 50을 Calculator 객체에 저장
 3. User 1 스레드 : 출력 100을 예상하지만 50이 출력
@@ -101,7 +101,7 @@
 
 # 스레드 상태 제어
 
-![](/draw/thread-status.png)
+![](/assets/thread-status.png)
 
 * 실행 중인 스레드의 상태를 변경하는 것을 말한다.
 * 실행 변화를 가져오는 메소드의 종류
@@ -118,21 +118,21 @@
 
 
 ## 다른 스레드에게 실행 양보 : yield()
-![](/draw/thread-yield.png)
+![](/assets/thread-yield.png)
 
 스레드가 처리하는 작업은 반복적인 실행을 위해 for문이나 while문을 포함하는 경우가 많다. 스레드가 시작되어 run() 메서드를 실행하면 블록을 무한 반복 실행한다. 만약 while 문은 어떤 실행문도 실행하지 않고 무의미한 반복을 한다면 이것보다 다른 스레드에게 실행을 양보하고 자신은 실행 대기 상태로 가는 것이 전체 프록램 성능에 도움이 된다. 
 
 이런 기능을 위해 스레드는 yield()메서드를 제공하고 있다. yield() 메서드를 호출한 스레드는 실행디기 상태로 돌아가고 동일한 우선수위 또는 높은 우선순위를 갖는 다른 스레드가 실행 기회를 가질 수 있도록 해준다.
 
 ## 다른 스레드의 종료를 기다림 : join()
-![](/draw/thread-join.png)
+![](/assets/thread-join.png)
 
 * `threadB.join()` 메서드는 Thread B를 일시 정지하는 것이 아니라, Thread A를 일시 정지 하는 것이다.
 * ThreadA가 ThreadB의 결과 값을 받아 작업이 진행될때 ThreadA는 `threadB.join()`를 통해서 ThreadB의 종료를 기다린다.
 * 계산 작업을 하는 스레드가 모든 계산 작업을 마쳤을 때, 계산 결과값을 받아 이용하는 경우 주로 사용
 
 ## 스레드 간 협업 : wait(), notify(), notifyAll()
-![](/draw/thread-notify.png)
+![](/assets/thread-notify.png)
 
 ## 동기화 메서드는 또는 블록에서만 호출 가능한 Object의 메소드
 * wait()
@@ -145,7 +145,7 @@
     * sleep() 무조건 주어진 시간이 다되야 실행 대기로 넘어간다.
 
 ## 두 개의 스레드가 교대로 번갈아 가며 실행해야 할 경우에 주로 사용
-![](/draw/thrad-share-data.png)
+![](/assets/thrad-share-data.png)
 
 * **wait(), notify(), notifyAll() 메서드는 동기화 메소드, 동기화 블록에서만 호출 가능**
 * 소비자 스레드가 한 번읽고 생성자 스레드에게 notify()를 호출해서 생성자 스레드가 새로운 데이터를 넣을 때까지 기다린다.
@@ -208,7 +208,7 @@ List<Runnable>      shutdownNow() 현재 작업 처리 중인 스레들을 inter
 ## 콜백 방식의 작업 완료 통보
 
 ### 콜백 이란?
-![](/draw/blocking-callback.png)
+![](/assets/blocking-callback.png)
 
 애플리케이션이 스레드에게 작업 처리를 요청한 후, 스레드가 작업을 완료하면 특정 메소드를 작동 실행하는 기법을 말한다. 이때 자동 실행되는 메서드를 콜백 메소드라고 한다.
 

diff --git a/JAVA/람다식-기초.md b/JAVA/람다식-기초.md
@@ -193,7 +193,7 @@ dobule ageAvg = list.stream() // 오리지날 스트림
 * 최종 처리: 반복, 카운터, 평균, 총합
 
 ## 스트림의 종류
-![](../../draw/stream-extends.png)
+![](../../assets/stream-extends.png)
 
 * BaseStream : 모든 스트림에서 사용할 수 잇는 공통 메서드들이 정의 되어 있을 뿐 코드에 직접적으로 사용되지 않는다.
 
@@ -269,7 +269,7 @@ List<Member> members = list.stream()
   * 병렬 처리 목적 : 작업 처리 시간을 줄임
   * 자바8부터 병렬 스트림을 제공하므로 컬렉션의 전체 요소 처리를 시간을 줄여줌
 
-![](../../draw/concurrency-Parallelism.png)
+![](../../assets/concurrency-Parallelism.png)
 
 * 동시성과 병렬성
   * 동시성: 멀티 스레드 환경에서 스레드가 번갈아 가며 실행하는 성질(싱글 코어 CPU)

diff --git a/JAVA/자바8-인액션.md b/JAVA/자바8-인액션.md
@@ -920,7 +920,7 @@ public class Fu {
     }
 }
 ```
-![](../draw/future-flow.png)
+![](../assets/future-flow.png)
 
 ExecutorService 에서 제공하는 스레드가 자신이 오래 걸리는 작업을 처리하는 동안 우리 스레드로 다른 작업을 동시에 실행할 수 있다. 다른 작업을 처리하다가 시간이 오래 걸리는 작업의 결과가 필요한 시점이 되었을때 Futurue의 get 메서드로 결과를 가져올 수 있다. get 메서드으 호출했을 때 이미 계산이 안료되어 결과가 준비되었다면 즉시 결과를 반환하지만 준비되지 않았다면 작업이 완료 될 때까지 우리 스레드를 블록 시킨다. 만약 오래 길리는 작업이 영원히 끝나지 않는다면 get 메서드를 오버로드해서 우리 스레드가 대기할 최대 타임아웃 시간을 설정할는 것이 좋다.
 

diff --git a/OS/운영체제_기초.md b/OS/운영체제_기초.md
@@ -258,7 +258,7 @@
 1. 실행 중지할 프로세스 정보를 해당 프로세스의 PCB에 업데이트해서, 메인 메모리에 저장
 2. 다음 실행할 프로세스 정보를 메인 메모리에 있는 해당 PCB 정보를 CPU에 넣고 실행
 
-![](/draw/context-switcing.png)
+![](/assets/context-switcing.png)
 1. 실행 중지할 프로세스 정보를 해당 프로세스의 PCB에 업데이트해서, 메인 메모리에 저장
 2. 다음 실행할 프로세스 정보를 메인 메모리에 있는 해당 **PCB 정보(PC, SP)를 CPU의 레지스터리**에 넣고 실행
 
@@ -285,7 +285,7 @@
 * 기본 파이프는 단방향 통신
 * fork()로 자식 프로세스 만들었을때, 부모와 자식간의 통신
 
-![](/draw/process-pipe.png)
+![](/assets/process-pipe.png)
 
 * 부모 프로세스에서 fd[1]을 기반으로 데이터를 생성
 * 자식 프로세스에서 fd[0]을 기반으로 데이터를 읽을 수 있음
@@ -304,7 +304,7 @@
 
 ### 공유 메모리
 
-![](/draw/shared-memory.png)
+![](/assets/shared-memory.png)
 * 노골적으로 kernel space에 메모리 공간을 만들고, 해당 공간을 변수처럼 쓰는 방식
 * message queue 처럼 FIFO 방식이 아니라. 해당 메모리 주소를 마치 변수처럼 접근하는 방식
 * 공유 메모리 key를 가지고, 여러 프로세스가 접근 가능
@@ -495,7 +495,7 @@
 * 어떤 페이지가 실제 물리 메모리에 없을 때 일어나는 인터럽트
 * 운영체제가 page fault가 일어나면, 해당 페이지를 물리 메모리에 올림
 
-![](/draw/page-interrupt-flow.png)
+![](/assets/page-interrupt-flow.png)
 
 1. CPU가 가상 주소를 요청
 2. MMU는 TLB에서 캐싱이 되있다면 메모리에서 바로 CPU에서 넘겨줌, 만약 없다면 CR3 레지스터리를 이용해서 페이지 테이블로 간다

diff --git a/Spring/rabbitmq.md b/Spring/rabbitmq.md
@@ -50,7 +50,7 @@ public void save(Comment comment){
 프로그래밍에서 MQ는 프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할 때 사용하는 방법을 말한다. 이러한 MQ를 오픈소스에 기반한 표준 프로토콜이 AMQP이다. AMQP 자체가 프로토콜을 의미하기 때문에 이 프로토콜을 구현한 MQ 제품들은 여러가지가 있으며 그 중하나가 RabbitMQ이다.
 
 ### AMQP의 구성요소와 라우팅 알고리즘
-![](/draw/rabbitmq.png)
+![](/assets/rabbitmq.png)
 
 * AMQP의 라우팅 모델은 Exchange, Queue, Binding으로 구성된다.
 
@@ -78,7 +78,7 @@ RabbitMQ는 AMQP를 구현한 오픈소스 메시지 소프트웨어 Pulisher(Pr
 > 출처 [RabibitMQ Tutorials]([http://blog.naver.com/PostView.nhn?blogId=tmondev&logNo=220419853534&parentCategoryNo=&categoryNo=6&viewDate=&isShowPopularPosts=false&from=postView](http://www.rabbitmq.com/getstarted.htm))
 
 
-![](/draw/rabbitmq-turorial.png)
+![](/assets/rabbitmq-turorial.png)
 
 ### Rabbit MQ Exchagne Type
 이름              | RabbitMQ 이름

diff --git a/Spring/security/basic.md b/Spring/security/basic.md
@@ -112,7 +112,7 @@
 * SecirtyContext Holder에 LocalThread에 담겨서 필요한 순간에 뿌려줄 수 있게됨
 
 
-![](/draw/spring-security.png)
+![](/assets/spring-security.png)
 
 ### AuthenticationManager : AuthenticationProvider 주머니
 * Builder 패턴으로 구현

diff --git a/Spring/transaction/transaction-lock.md b/Spring/transaction/transaction-lock.md
@@ -4,7 +4,7 @@
 
 한 주문 애그리거트에 대해 운영자는 배송 준비 상태로 변경할 때 사용자는 배송지 주소를 변경하면 어떻게 될까? 아래 그림은 운영자와 고객이 동시에 한 주문 애그리거트를 수정하는 과정을 보여준다. (배송 상태로 변경되면 더 이상 배송지 변경은 할 수 없다.)
 
-![](../../draw/transaction-thread.png)
+![](../../assets/transaction-thread.png)
 
 운영자 스레드와 고객 스레드는 같은 주문 애그리거트를 나타내는 다른 객체를 구하게 된다 (트랜잭션 마다 리포지토리라는 새로운 애그리거트를 생성한다.)
 
@@ -25,7 +25,7 @@
 REPEATABLE_READ은 트랜잭션이 지속되는 동안 다른 트랜잭션이 해당 필드를 변경할 수 없는 격리 레벨이다. **이것으로 위의 문제를 해결할 수 있지는 않다.**
 
 
-![](../../draw/transaction-thread.png)
+![](../../assets/transaction-thread.png)
 
 1. 운영자 스레드가 주문 애그리거트를 구함 (배송 이전 상태)
 2. 고객 스레드가 주문 애그리거트를 구함 (배송 이전 상태) REPEATABLE_READ 속성이므로 select 트랜잭션이 진행중에 있더라도 select는 진행됨
@@ -42,7 +42,7 @@ REPEATABLE_READ은 트랜잭션이 지속되는 동안 다른 트랜잭션이
 ## 선점 잠금
 선점 잠금은 먼저 애그리거트를 구한 스레드가 애그리거트 사용이 끝날 때까지 다른 스레드가 해당 애그리거트를 수정하는 것을 막는 방식이다.
 
-![](../../draw/transaction-thread2.png)
+![](../../assets/transaction-thread2.png)
 
 스레드1 선점 잠금방식으로 애그리거트를 구한 뒤 이에서 스레드2가 같은 애그리거트를 구하고 있는데, 이 경우 스레드2는 스레드1이 애그리거트에대한 잠금을 해제할 때 까지 블로킹된다.
 
@@ -53,7 +53,7 @@ REPEATABLE_READ은 트랜잭션이 지속되는 동안 다른 트랜잭션이
 
 ### 선점 잠금 적용
 
-![](../../draw/transaction-thread3.png)
+![](../../assets/transaction-thread3.png)
 
 1. 운영자 스레드가 먼저 선점 잠금 방식으로 주문 애그리거트를 구함
 2. 고객 스레드는 운영자 스레드가 잠금을 해제할 때까지 고객 스레드는 대기 상태
@@ -121,7 +121,7 @@ WHERE aggid =? and version = 현재 버전
 
 ### 비선점 잠금을 이용한 트랜잭션 충돌 방지
 
-![](../../draw/transacion-thread4.png)
+![](../../assets/transacion-thread4.png)
 
 1. 스레드 1 애그리거트 조회
 2. 스레드 2 애그리거트 조회

diff --git a/Spring/transaction/transaction-study.md b/Spring/transaction/transaction-study.md
@@ -10,7 +10,7 @@
 
 
 ## 트랜잭션 동기화 작업 흐름
-![](../../draw/TransactionSynchronizations.png)
+![](../../assets/TransactionSynchronizations.png)
 
 
 * (1) UserService Connection을 생성하고
@@ -52,7 +52,7 @@ UserService의 코드가 특정 트랜잭션 방법에 의존적이지 않고
 
 **스프링은 트랜잭션 기술의 공통점을 담은 트랜잭션 추상화 기술을 제공하고 있다.** 이를 이요하면 애플리케이션에서 직접 각 기술의 트랜잭션 API를 사용 하지 않고도, 일관된 방식으로 트랜잭션을 제어하는 트랜잭션 경계설정 작업이 가능해진다.
 
-![](../../draw/PlatformTransactionManager-2.png)
+![](../../assets/PlatformTransactionManager-2.png)
 
 JDBC를 이용하는 경우 Connection을 생성하고 나서 트랜잭션을 시작했다. 하지만 PlatformTransactionManager에서 트랜잭션을 가져오는 요청인 getTransacion() 메서드를 호출하기만 하면된다. 필요에 따라 트랜잭션 매니저가 DB 커넥션을 가져오는 작업도 같이 수행하기 때문이다. 트랜잭션을 가져온다는 것은 일단 트랜잭션을 시작한다는 의미라고 생각하자.
 

diff --git a/assets/Client Credentials Grant Type.png b/assets/Client Credentials Grant Type.png
diff --git a/draw/PlatformTransactionManager-2.png → assets/PlatformTransactionManager-2.png b/draw/PlatformTransactionManager-2.png → assets/PlatformTransactionManager-2.png
diff --git a/draw/TransactionSynchronizations.png → assets/TransactionSynchronizations.png b/draw/TransactionSynchronizations.png → assets/TransactionSynchronizations.png
diff --git a/draw/blocking-callback.png → assets/blocking-callback.png b/draw/blocking-callback.png → assets/blocking-callback.png
diff --git a/draw/ca-com.png → assets/ca-com.png b/draw/ca-com.png → assets/ca-com.png
diff --git a/draw/concurrency-Parallelism.png → assets/concurrency-Parallelism.png b/draw/concurrency-Parallelism.png → assets/concurrency-Parallelism.png
diff --git a/draw/context-switcing.png → assets/context-switcing.png b/draw/context-switcing.png → assets/context-switcing.png
diff --git a/draw/cs-computer.png → assets/cs-computer.png b/draw/cs-computer.png → assets/cs-computer.png
diff --git a/draw/cu-alu.png → assets/cu-alu.png b/draw/cu-alu.png → assets/cu-alu.png
diff --git a/draw/excpetion-class-diagram.png → assets/excpetion-class-diagram.png b/draw/excpetion-class-diagram.png → assets/excpetion-class-diagram.png
diff --git a/draw/future-flow.png → assets/future-flow.png b/draw/future-flow.png → assets/future-flow.png
diff --git a/draw/java-thread-single-multy.png → assets/java-thread-single-multy.png b/draw/java-thread-single-multy.png → assets/java-thread-single-multy.png
diff --git a/assets/job-job-instance-job-execution.png b/assets/job-job-instance-job-execution.png
diff --git a/draw/msa-cloud-bus.png → assets/msa-cloud-bus.png b/draw/msa-cloud-bus.png → assets/msa-cloud-bus.png
diff --git a/draw/msa-config-server.png → assets/msa-config-server.png b/draw/msa-config-server.png → assets/msa-config-server.png
diff --git a/draw/page-interrupt-flow → assets/page-interrupt-flow b/draw/page-interrupt-flow → assets/page-interrupt-flow
diff --git a/draw/page-interrupt-flow.png → assets/page-interrupt-flow.png b/draw/page-interrupt-flow.png → assets/page-interrupt-flow.png
diff --git a/draw/process-pipe.png → assets/process-pipe.png b/draw/process-pipe.png → assets/process-pipe.png
diff --git a/draw/rabbitmq-turorial.png → assets/rabbitmq-turorial.png b/draw/rabbitmq-turorial.png → assets/rabbitmq-turorial.png
diff --git a/draw/rabbitmq.png → assets/rabbitmq.png b/draw/rabbitmq.png → assets/rabbitmq.png
diff --git a/draw/shared-memory.png → assets/shared-memory.png b/draw/shared-memory.png → assets/shared-memory.png
diff --git a/draw/spring-security.png → assets/spring-security.png b/draw/spring-security.png → assets/spring-security.png
diff --git a/draw/stream-extends.png → assets/stream-extends.png b/draw/stream-extends.png → assets/stream-extends.png
diff --git a/draw/thead-shduler.png → assets/thead-shduler.png b/draw/thead-shduler.png → assets/thead-shduler.png
diff --git a/draw/thrad-share-data.png → assets/thrad-share-data.png b/draw/thrad-share-data.png → assets/thrad-share-data.png
diff --git a/draw/thread-join.png → assets/thread-join.png b/draw/thread-join.png → assets/thread-join.png
diff --git a/draw/thread-notify.png → assets/thread-notify.png b/draw/thread-notify.png → assets/thread-notify.png
diff --git a/draw/thread-status.png → assets/thread-status.png b/draw/thread-status.png → assets/thread-status.png
diff --git a/draw/thread-synchronization.png → assets/thread-synchronization.png b/draw/thread-synchronization.png → assets/thread-synchronization.png
diff --git a/draw/thread-yield.png → assets/thread-yield.png b/draw/thread-yield.png → assets/thread-yield.png
diff --git a/draw/transacion-thread4.png → assets/transacion-thread4.png b/draw/transacion-thread4.png → assets/transacion-thread4.png
diff --git a/draw/transaction-thread.png → assets/transaction-thread.png b/draw/transaction-thread.png → assets/transaction-thread.png
diff --git a/draw/transaction-thread2.png → assets/transaction-thread2.png b/draw/transaction-thread2.png → assets/transaction-thread2.png
diff --git a/draw/transaction-thread3.png → assets/transaction-thread3.png b/draw/transaction-thread3.png → assets/transaction-thread3.png
diff --git a/ca/ca-basic.md b/ca/ca-basic.md
@@ -27,7 +27,7 @@
 
 ## 컴퓨터의 구성 요소
 
-![](/draw/ca-com.png)
+![](/assets/ca-com.png)
 
 * 입력 (Input)
 * 출력 (Output)
@@ -37,7 +37,7 @@
 
 
 ## 구성요서별 역할
-![](/draw/cs-computer.png)
+![](/assets/cs-computer.png)
 
 * 프로세스
   * 메모리로 부터 명령과 데이터를 얻음
@@ -64,7 +64,7 @@
 
 #### 프로세스의 동작 과정
 
-![](/draw/cu-alu.png)
+![](/assets/cu-alu.png)
 
 * 제어유닛(Control Unit) - 명령어를 순서대로 읽어와 차례대로 실행, 제어신호를 생성하여 주변 장치에게 보냄
 * 레지스터

diff --git a/draw/Client Credentials Grant Type.png b/draw/Client Credentials Grant Type.png
diff --git a/draw/Implicit Grant.png b/draw/Implicit Grant.png
diff --git a/draw/Resource Owner Password Credentials Grant.png b/draw/Resource Owner Password Credentials Grant.png
diff --git a/draw/acl-sid.png b/draw/acl-sid.png
diff --git a/draw/bach-process.png b/draw/bach-process.png
diff --git a/draw/batch-flow.png b/draw/batch-flow.png
diff --git a/draw/batch-obejct-relrationship.png b/draw/batch-obejct-relrationship.png
diff --git a/draw/chun-process.png b/draw/chun-process.png
diff --git a/draw/cors-.png b/draw/cors-.png
diff --git a/draw/job-job-instance-job-execution.png b/draw/job-job-instance-job-execution.png
diff --git a/draw/networ-.png b/draw/networ-.png
diff --git a/draw/proxy-class.png b/draw/proxy-class.png
diff --git a/draw/proxy.png b/draw/proxy.png
diff --git a/draw/security-3.png b/draw/security-3.png
diff --git a/draw/security-FilterChainProxy.png b/draw/security-FilterChainProxy.png
diff --git a/draw/security-authentication-filter.png b/draw/security-authentication-filter.png
diff --git a/draw/spring-mvc-flow.png b/draw/spring-mvc-flow.png
diff --git a/도서/DDD-START.md b/도서/DDD-START.md
@@ -393,7 +393,7 @@ MemberService라는 곳에 모든 로직이 담겨있다면 MemberService의 책
 
 한 주문 애그리거트에 대해 운영자는 배송 준비 상태로 변경할 때 사용자는 배송지 주소를 변경하면 어떻게 될까? 아래 그림은 운영자와 고객이 동시에 한 주문 애그리거트를 수정하는 과정을 보여준다. (배송 상태로 변경되면 더 이상 배송지 변경은 할 수 없다.)
 
-![](https://github.com/cheese10yun/TIL/raw/master/draw/transaction-thread.png)
+![](https://github.com/cheese10yun/TIL/raw/master/assets/transaction-thread.png)
 
 운영자 스레드와 고객 스레드는 같은 주문 애그리거트를 나타내는 다른 객체를 구하게 된다 (트랜잭션 마다 리포지토리라는 새로운 애그리거트를 생성한다.)
 
@@ -414,7 +414,7 @@ MemberService라는 곳에 모든 로직이 담겨있다면 MemberService의 책
 REPEATABLE_READ은 트랜잭션이 지속되는 동안 다른 트랜잭션이 해당 필드를 변경할 수 없는 격리 레벨이다. **이것으로 위의 문제를 해결할 수 있지는 않다.**
 
 
-![](https://github.com/cheese10yun/TIL/raw/master/draw/transaction-thread.png)
+![](https://github.com/cheese10yun/TIL/raw/master/assets/transaction-thread.png)
 
 1. 운영자 스레드가 주문 애그리거트를 구함 (배송 이전 상태)
 2. 고객 스레드가 주문 애그리거트를 구함 (배송 이전 상태) REPEATABLE_READ 속성이므로 select 트랜잭션이 진행중에 있더라도 select는 진행됨
@@ -431,7 +431,7 @@ REPEATABLE_READ은 트랜잭션이 지속되는 동안 다른 트랜잭션이
 ## 선점 잠금
 선점 잠금은 먼저 애그리거트를 구한 스레드가 애그리거트 사용이 끝날 때까지 다른 스레드가 해당 애그리거트를 수정하는 것을 막는 방식이다.
 
-![](https://github.com/cheese10yun/TIL/raw/master/draw/transaction-thread2.png)
+![](https://github.com/cheese10yun/TIL/raw/master/assets/transaction-thread2.png)
 
 스레드1 선점 잠금방식으로 애그리거트를 구한 뒤 이에서 스레드2가 같은 애그리거트를 구하고 있는데, 이 경우 스레드2는 스레드1이 애그리거트에대한 잠금을 해제할 때 까지 블로킹된다.
 
@@ -442,7 +442,7 @@ REPEATABLE_READ은 트랜잭션이 지속되는 동안 다른 트랜잭션이
 
 ### 선점 잠금 적용
 
-![](https://github.com/cheese10yun/TIL/raw/master/draw/transaction-thread3.png)
+![](https://github.com/cheese10yun/TIL/raw/master/assets/transaction-thread3.png)
 
 1. 운영자 스레드가 먼저 선점 잠금 방식으로 주문 애그리거트를 구함
 2. 고객 스레드는 운영자 스레드가 잠금을 해제할 때까지 고객 스레드는 대기 상태
@@ -510,7 +510,7 @@ WHERE aggid =? and version = 현재 버전
 
 ### 비선점 잠금을 이용한 트랜잭션 충돌 방지
 
-![](https://github.com/cheese10yun/TIL/raw/master/draw/transacion-thread4.png)
+![](https://github.com/cheese10yun/TIL/raw/master/assets/transacion-thread4.png)
 
 1. 스레드 1 애그리거트 조회
 2. 스레드 2 애그리거트 조회

diff --git a/도서/스프링5레시피.md b/도서/스프링5레시피.md
@@ -2578,7 +2578,7 @@ public class AccountServiceJUnit4ContextTests {
     }
 
     @Test
-    public void withDraw() {
+    public void withdraw() {
         accountService.withdraw(TEST_ACCOUNT_NO, 50);
         assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 50, 0);
     }
@@ -2640,8 +2640,8 @@ public class AccountServiceJUnit4ContextTests extends AbstractTransactionalJUnit
     }
 
     @Test
-    public void withDraw() {
-        accountService.withdraw(TEST_ACCOUNT_NO, 50);
+    public void withassets() {
+        accountService.withassets(TEST_ACCOUNT_NO, 50);
         double balance = jdbcTemplate.queryForObject(
                 "SELECT BALANCE FROM ACCOUNT WHERE ACCOUNT_NO = ?",
                 Double.class, TEST_ACCOUNT_NO);
@@ -2700,8 +2700,8 @@ public class AccountServiceJUnit4ContextTests extends AbstractTransactionalJUnit
 
     @Test
     @Repeat(5)
-    public void withDraw() {
-        accountService.withdraw(TEST_ACCOUNT_NO, 50);
+    public void withassets() {
+        accountService.withassets(TEST_ACCOUNT_NO, 50);
         double balance = jdbcTemplate.queryForObject(
                 "SELECT BALANCE FROM ACCOUNT WHERE ACCOUNT_NO = ?",
                 Double.class, TEST_ACCOUNT_NO);

diff --git a/도서/함께_자라기.md b/도서/함께_자라기.md
@@ -43,3 +43,27 @@
 
 해자일 프로젝트에서는 지금 내가 한 행동의 피드백을 10분 후, 한 시간 후, 하루 후, 일주일 후 등 여러 주기를 톨해 지속적으로 얻을 수 있습니다. **인간의 경우도 피드백 주기가 길어지면 학습이 잘 안됩니다.** **무슨일이 끝나면 항상 회고 라는 활동을 해라**
 
+
+## 달인 이되는 비결 
+
+1. **실력을 개선하려는 동기가** 있어야 하고
+2. 구체적인 피드백을 적절한 시기에 받아야 한다.
+
+단순히 반복만 한다고 해서 달인이 될수 없습니다. **특정 영역에서 개인이성취할 수 있는 최고 수준의 퍼포먼스는 경험을 오래 한다고 해서 자동으로 얻을 수 있는 것이 아닙니다.**
+
+### 전문성 형성에 타당성과 피드백의 중요성
+
+역사나 정치학의 전문가와 일반인이 장기적인 정치 판도를 예측했는데, 결과에는 별 차이가 없습니다. 주가를 예측한 실험에서도 펀드 매니저나 원숭이나 큰 차이가 없었고, 오히려 전문가가 더 못한 경우도 있습니다. 
+
+**피드백 조건이 필요하다는 의미는 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야 한다는 걸 말합니다. 수십 년 동안 한 가지 일을 하면서 전문가가 안되는 비결이 있다면 이 타탕성과 피드백이 부족한 환경에서 일하는 겁니다.**
+
+### 당신이 제자리 걸음인 이유
+실력을 높이기 위해서는 **의도적 수련이 중요합니다.**
+
+#### 의도적 수련의 필수조건, 적절한 난이도
+의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 합니다. 
+
+
+
+
+
-Original file line number
+Diff line change
@@ Expand Up / @@ -920,7 +920,7 @@ public class Fu { @@
         }
     }
     ```
-    ![](../draw/future-flow.png)
+    ![](../assets/future-flow.png)
     ExecutorService 에서 제공하는 스레드가 자신이 오래 걸리는 작업을 처리하는 동안 우리 스레드로 다른 작업을 동시에 실행할 수 있다. 다른 작업을 처리하다가 시간이 오래 걸리는 작업의 결과가 필요한 시점이 되었을때 Futurue의 get 메서드로 결과를 가져올 수 있다. get 메서드으 호출했을 때 이미 계산이 안료되어 결과가 준비되었다면 즉시 결과를 반환하지만 준비되지 않았다면 작업이 완료 될 때까지 우리 스레드를 블록 시킨다. 만약 오래 길리는 작업이 영원히 끝나지 않는다면 get 메서드를 오버로드해서 우리 스레드가 대기할 최대 타임아웃 시간을 설정할는 것이 좋다.
@@ Expand Down @@