일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- spring boot
- 게이트웨이
- 트리
- 이분 매칭
- Spring Cloud Config
- 플로이드 와샬
- 이분 탐색
- 완전 탐색
- Gradle
- dp
- 메모이제이션
- 주울
- Logback
- 도커
- 구현
- docker-compose
- 비트마스킹
- 백트래킹
- 다익스트라
- Java
- ZuulFilter
- 구간 트리
- Zuul
- spring cloud
- 스택
- BFS
- 스프링 시큐리티
- 달팽이
- 서비스 디스커버리
- 유레카
- Today
- Total
목록Java (5)
Hello, Freakin world!

간단하게 비유하자면 이 클래스는 Map 처럼 동작합니다. 스레드의 참조를 키 값으로 하기 때문에 같은 ThreadLocal이 여러 스레드에 공유되어 값을 저장해도 특정 스레드에 저장된 값이 다른 스레드에 의해 영향받지 않습니다. 간단한 예제 코드로 확인해보겠습니다. import org.junit.jupiter.api.Test; public class TestThreadLocal { ThreadLocal threadLocal = ThreadLocal.withInitial(() -> "default"); @Test public void test() throws InterruptedException { threadLocal.set("main"); Thread myThread = new Thread(() -> ..
www.acmicpc.net/problem/11286 11286번: 절댓값 힙 첫째 줄에 연산의 개수 N(1≤N≤100,000)이 주어진다. 다음 N개의 줄에는 연산에 대한 정보를 나타내는 정수 x가 주어진다. 만약 x가 0이 아니라면 배열에 x라는 값을 넣는(추가하는) 연산이고, x가 0� www.acmicpc.net 물론 언어에서 제공하는 우선순위 큐를 이용할 수도 있겠지만... 그닥 재미는 없어보인다. 구현 방식에 특별하게 추가하는 건 없다. 기존의 전형적인 힙 구현 코드에 요소가 같을 경우 작은 수를 반환한다는 조건을 추가하면 된다. (그럼에도 불구하고 8번 틀렸다 ㅋㅋㅋㅋㅋ. >= 와 > 차이로 인한 차이였는데 왠만한 테스트케이스가 다 맞게 나와서 더 애를 먹었다. 테스트 케이스 찾기는 포기하고..
www.acmicpc.net/problem/1525 1525번: 퍼즐 세 줄에 걸쳐서 표에 채워져 있는 아홉 개의 수가 주어진다. 한 줄에 세 개의 수가 주어지며, 빈 칸은 0으로 나타낸다. www.acmicpc.net 풀이를 둘러보니 상태를 저장하는 방법이 꽤 여러 가지였습니다. 각 요소의 값이 모두 1자리기 때문에 문자열이나 그냥 정수로 상태를 표현한 풀이도 가능합니다. 하지만 값이 한 자리를 넘어가는 순간 값들을 분리해야 되기 때문에 다른 방법이 필요할겁니다. 비트마스킹은 입력의 범위가 크지 않다면 일반적인 대안이 될 수 있습니다. 이 문제의 경우 0~9까지의 수를 표현하기 위해 4자리의 비트가 필요합니다. 수를 모두 9개이므로 36비트가 필요하겠네요. 자바 int 자료형은 32비트라서 안되고 lo..
no1linux.org/hottips/28242 No1.Linux 팁및 강좌 - [시스템] Alternatives(Update-altenatives)로 하나의 심볼릭 링크로 여러 패키지 관리 하나의 심볼릭 링크로 여러 개의 패키지 관리하기 - update-alternatives 1. 개 요 버전이 각기 다른 패키지에 대해서 동일한 심볼릭 링크를 사용해야 할 경우에 어떻게 해야 할까? 원하는 버전으로 � no1linux.org

오해 동기 방식의 IO 작업에서 서버소켓은 한 클라이언트와 통신 중일때, 다른 클라이언트와 통신할 수 없다. 그래서 나는 서버소켓에서 accept()를 호출하면 서버소켓과 클라이언트 소켓이 서로 1:1로 연결되는 이미지로 이해했는데, 이는 2퍼센트 부족한 이해였다. 부족했던 2퍼센트 때문에 어떻게 동기방식의 서버가 다수의 클라이언트의 요청을 처리하게 만들지 상당히 고민했었는데, 몇몇 예제들을 살펴보니 내가 accept()의 동작 방식을 완전히 잘못 이해하고 있다는 것을 깨달았다. 추정 이 그림은 동작테스트를 통해 내가 추정하는 모델이다. 클라이언트에게 공개되는 entry port가 존재한다. accept는 entry port로 접근하는 클라이언트 소켓을 내부에서 자동 지정된 포트 번호의 소켓에 매핑해주는..