Multithreading - 3

Deadlock 두개 이상의 쓰레드가 영원히 blocked되어있는 상태 지정한 개체와 연결된 잠금을 대기하는 동안 동기화된 키워드로 인해 실행 중인 스레드가 차단될 경우 Deadlock이 발생 Deadlock을 예방하는 방법 Lock을 사용하지 않음 같은 순서로 lock을 가져감 일정 시간이 지난 후 lock을 release하게 만듬

Multithreading - 2

Synchronzied 자바 키워드 synchronized block 혹은 method 를 통해 특정 object에 lock을 검(intrinsic lock or monitor lock) Multithreading 환경에서 공유 자원에 엑세스 할때 사용 -> synchronized를 사용하면 그 리소스는 하나의 스레드만 접근할수 있게됨 (JVM이 관리) Synchronized method vs Synchronized block Synchronized method는 메써드 전체를 동기화시킴 Synchronzied block은 블락안에 있는 코드들만 동기화의 대상이 됨 Synchronized block은 lock의 대상이 되는 범위를 줄여주기 때문에 성능상으로 이점이 있음 -> 중요한 부분만 동기화 시키는게 중요

MultiThreading - 1

MultiThreading이란 여러가지 thread를 동시에 실행하는 것 Thread란 processing의 가장 작은 단위, MultiProcessing과 MultiTHreading 모두 multitasking을 위해 사용됨 Multithread 프로그램은 동시에 가용될 수 있는 여러개의 스레드가 존재 -> 하나의 시스탬이 동시에 여러가지 업무를 처리할 수 있음 장점 CPU의 유휴기간을 최소화 하고 CPU 시간을 최대한 활용 각자의 thread는 독립적이기 때문에 클라이언트를 block하지 않음 마찬가지로 각 thread는 독립적이기 때문의 하나의 thread에서의 exception이 다른 스레드에 영향을 미치지 않음

Stateful vs Stateless

Stateful - 서버에 세션의 형태로 클라이언트의 상태를 저장 - 서버에 상태가 저장되어 있기 때문에 이후에 클라이언트의 엑세스를 검증하지 않아도 됨 - 서버가 확장된 경우 확장된 서버에 접근이 불가능함(상태가 저장되어 있지 않음) Stateless - 서버에 상태를 저장하지 않음 - 토큰을 발급 -> 클라이언트는 발급된 토큰을 이용해 소통 - 서버는 요청마다 전달받은 토큰을 검증 - 서버에 저장된 상태에 의존하지 않게 때문에 서버 확장에 용이함

Publish-Subscribe Architecture 공부 내용 정리

기존 Request-Response 구조의 장단점 장점 사용이 용이함 Stateless (HTTP) 단점 Reciever가 여러개 있는 경우 스케일이 용이하지 않음 여러 서비스간 커플링이 발생 요청을 처리하기 위해 클라이언트와 서버가 동시에 작동하는 상태여야 함 문제들을 해결하기 위해 chaining, retries, circuit breaker등을 사용 Publish-Subscribe 모델 Message Queue/Topic이 middleware layer형식으로 존재 Publihser는 message queue/topic에 message를 post함 Subscriber는 새로운 메시지가 있는 경우 알림을 받고 정해진 일을 수행 Redis, kafka, RabbitMQ 등 장점 여러 receiver가 있어도 확장이 용이 디커플링 캐싱 Publisher나 Subscriber가 작동하지 않아도 동작 Microservice에 좋음 event-driven구조와 어울림 단점 메시지 전송 이슈 (정확하게 하나의 메시지가 한번만 전송을 보장해야함, Two General's Problem) Network Saturation (push모델의 경우 너무 많은 메시지를 푸슁, pull 모델의 경우 false attempts 그래도 확장이 문제 Two General's Problem - 메시지를 받았는데 메시지를 받아서 처리했는지 확인할 방법이 없음 -> 같은 오더를 여러번 전송하게 됨 -> 같은 오더가 여러번 처리됨 - 해결방안 : idempotency token -> 서버는 idempotency token을 가지고 있다가 같은 token을 가진 요청이 다시 들어오면 먼저 요청의 카피를 계속 전송함 -> 같은 요청이 반복적으롣 들어와도 한번만 실행됨

깃허브에 푸쉬했는데 contribution이 증가하지 않는 현상

1일 1 커밋을 실천하기 위해 열심히 커밋을 했는데 이틀 연속 contribution이 증가하지 않는 현상을 발견했다. 공식 홈페이지에는 다음 조건들을 모두 충족해야만 contribution이 증가한다고 나와있다. 커밋한 이메일 주소가 깃허브 어카운트와 동일/연동되어 있어야함 포크한 repository에 한 commit은 카운트 되지 않음 repository의 기본 저장소 혹은 gh-pages 브랜치에 커밋 되어야함 나같은 초보자가 보기에는 이해가 어려워 따로 검색을 해보니 로컬 깃 유저 정보가 repository에 등록되어 있지 않은게 이유였다. git config --global user.name NAME git config --global user.email EMAIL 를 실행해서 간단하게 해결했다 참조: https://docs.github.com/en/github/setting-up-and-managing-your-github-profile/managing-contribution-graphs-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile https://marshallslee.tistory.com/entry/%EA%B9%83%ED%97%88%EB%B8%8C%EC%97%90-%EC%86%8C%EC%8A%A4%EB%A5%BC-%ED%91%B8%EC%8B%9C%ED%96%88%EB%8A%94%EB%8D%B0-contributions%EC%9D%B4-%EC%97%85%EB%8D%B0%EC%9D%B4%ED%8A%B8-%EB%90%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EA%B2%BD%EC%9A%B0

자바 디자인 패턴 이해 2강 정리

어뎁터 패턴 요구 사항에 맞추서 기능(알고리즘)을 변경해 사용할 수 있다 연관이 없는 두 객체를 묶어서 사용할 수 있다 직접적으로 연결될 수 없는 두 인터페이스 사이를 연결해주는 커넥터(connector)의 역할을 한다. 변경하고자 하는 클래스(Adaptee)를 인터페이스로 감싼 후 요구사항에 호환되게 변경을 해준다 사용 시기 사용하고자 하는 기능이 있는데 현재 어플리케이션과 맞지 않는 경우 클라이언트의 요구사항과 현재의 어플리케이션이 맞지 않는 경우 원본 소스의 변경 없이 레거시 코들르 재활용하고 싶은 경우 참조 https://www.baeldung.com/java-adapter-pattern https://www.youtube.com/watch?time_continue=732&v=gJDZ7pcvlAU&feature=emb_title

자바 디자인 패턴의 이해 1강 정리

개념 인터페이스 델리게이트 전략 패턴 인터페이스 기능에 대한 선언과 구현을 분리한다. 기능을 사용 통로 델리게이트 위임하다 - 특정 객체의 기능을 사용하기 위해 다른 객채의 기능을 빌려서 사용하는 것 전략 패턴 여러 알고리즘을 하나의 추상적인 접근점을 만들어 접근점에서 서로 교환 가능하도록 하는 패턴 인터페이스라는 하나의 통로를 이용 이미지 출처: http://www.mcdonaldland.info/2007/11/28/40/