<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://jinsanpark.github.io/</id><title>삽질 기록</title><subtitle>자바 공부 기록 및 풀이 정리</subtitle> <updated>2026-10-07T14:32:10+09:00</updated> <author> <name>JinsanPark</name> <uri>https://jinsanpark.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://jinsanpark.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://jinsanpark.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 JinsanPark </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>(Voyage) 서버가 맛이 가면</title><link href="https://jinsanpark.github.io/posts/Embedding-Project-16/" rel="alternate" type="text/html" title="(Voyage) 서버가 맛이 가면" /><published>2026-10-07T13:00:00+09:00</published> <updated>2026-10-07T13:00:00+09:00</updated> <id>https://jinsanpark.github.io/posts/Embedding-Project-16/</id> <content type="text/html" src="https://jinsanpark.github.io/posts/Embedding-Project-16/" /> <author> <name>JinsanPark</name> </author> <category term="Project" /> <category term="newsFinder" /> <summary>지난 시간 저번 시간에 보야지 서버가 터지면 무한 대기를 해야한다고 했었죠. 그러면 간단하게 해결책이랑 몇가지 현 코드에서 발생하는 문제를 수정해 보도록 합시다. 연결과 읽기 API를 호출할때 대기 시간이 대략 180ms 정도인데, 만약 서버가 맛이 갔다고 합시다. 근데 이것도 종류가 있습니다. 일단 연결은 간단하고, 쿡쿡 찔러서 반응을 안하면 연결이 안된다는 건데, 이거는 판단하기 쉽죠. 문제는 연결은 됐는데 서버가 일이 너무 많아서 처리 하다가 멈추는 거에요. 제일 흔하죠. 뭐 AI 같은거 API가져다가 쓰면 한참 있다가 503 오류 왕왕 보잖아요? 그런거 처럼요. 문제가 오래 걸린다는거에요. 저는 타임 아웃을 하나로 걸려고 합니다. 간단한 대신 검색 쪽은 느슨하게요. 구현 Simpl...</summary> </entry> <entry><title>락은 최소한으로</title><link href="https://jinsanpark.github.io/posts/Embedding-Project-15/" rel="alternate" type="text/html" title="락은 최소한으로" /><published>2026-09-14T13:30:00+09:00</published> <updated>2026-10-07T14:31:16+09:00</updated> <id>https://jinsanpark.github.io/posts/Embedding-Project-15/</id> <content type="text/html" src="https://jinsanpark.github.io/posts/Embedding-Project-15/" /> <author> <name>JinsanPark</name> </author> <category term="Project" /> <category term="newsFinder" /> <summary>지난 시간 저번 시간에 다른 동시 입력시에 다른 스레드도 L1 캐시값을 그대로 받아서 더 빠르게 돌려주는 걸 해본다 했으니, 오늘 해보도록 합시다. 오늘은 길지 않습니다. 길어보이려고 코드도 안접을거에요. 진짜 별거 없음 queryVectorCacheRepository.save(cache);를 따로 빼줘야 합니다. 근데 따로 빼주면 코드 어딘가에 빨간줄이 생기는데, 어디일까요? cache가 빨게집니다. 간단하게 그냥 락 밖에서 선언해주면 끝입니다. 그리고 저번에 만들었던 try/catch 구분이랑 시간 측정 하는 부분도 락 밑으로 따로 빼주면 됩니다. QueryVectorCache cache; // 따로 lock 밖에서 선언 synchronized (lo...</summary> </entry> <entry><title>동시 요청에 API를 1번만</title><link href="https://jinsanpark.github.io/posts/Embedding-Project-14/" rel="alternate" type="text/html" title="동시 요청에 API를 1번만" /><published>2026-09-11T15:00:00+09:00</published> <updated>2026-09-14T14:04:50+09:00</updated> <id>https://jinsanpark.github.io/posts/Embedding-Project-14/</id> <content type="text/html" src="https://jinsanpark.github.io/posts/Embedding-Project-14/" /> <author> <name>JinsanPark</name> </author> <category term="Project" /> <category term="newsFinder" /> <summary>지난 시간 지난시간에 캐시 두 단에서 전부 미스가 나면, API를 두번 호출하는 거 해결한다고 했었죠. 그러면 한번 해결 해 봅시다. 나도 똥싸개 빨리 좀 요청이 세가지가 들어왔습니다. 하나는 소변이고, 두개는 큰거네요. 근데 화장실에 소변칸 하나, 변기칸 하나가 있다고 해봅시다. 저희 코드는 줄을 안서요. 그냥 들어가요. 되게 비효율적이죠? 그렇다면, 볼일끼리 서로 줄을 다르게 세우면 될거 아니에요. 큰거는 이쪽줄, 작은거는 저쪽줄로 해서. 이렇게 서로 락을 쪼개는게 바로 키별 락이에요. 락을 어디에 보관하나? Map&amp;lt;String, Object&amp;gt; locks; HashMap을 쓸 수도 있는데, 저는 못씁니다. 일단 두 스레드 동시에 put 요청이 들어오면 망가질 수 있기 때문...</summary> </entry> <entry><title>containsKey를 꼭 만져야 동시성을 해결하나?</title><link href="https://jinsanpark.github.io/posts/Embedding-Project-13/" rel="alternate" type="text/html" title="containsKey를 꼭 만져야 동시성을 해결하나?" /><published>2026-09-09T16:00:00+09:00</published> <updated>2026-09-14T14:04:50+09:00</updated> <id>https://jinsanpark.github.io/posts/Embedding-Project-13/</id> <content type="text/html" src="https://jinsanpark.github.io/posts/Embedding-Project-13/" /> <author> <name>JinsanPark</name> </author> <category term="Project" /> <category term="newsFinder" /> <summary>지난 시간 저번 시간에 containsKey 어쩌구 하면서 null값 받을 수도 있다고 그랬죠. 그러면 오늘 이어서 알아봅시다. 안전? if (lruCached.containsKey(norm)) { normToVector = lruCached.get(norm); return normToVector; } 위 코드에서 containsKey에다가 synchronized를 오버라이드를 했다고 가정해봅시다. lruCached에 put/get에도 오버라이드 되어있고요. 그럼 동시 요청시 안전할까요? 답은 안전하지 않습니다. 왜냐면, synchronized는 잠그는 범위가 달라요. 락의 단위가 메서드 도는 동안만 이고, 메서드가 끝나면 바로 풀어버려요. 그래서 무슨 일이 발생하냐면 ...</summary> </entry> <entry><title>synchronized으로 동시성 일부 해결하기</title><link href="https://jinsanpark.github.io/posts/Embedding-Project-12/" rel="alternate" type="text/html" title="synchronized으로 동시성 일부 해결하기" /><published>2026-09-08T09:00:00+09:00</published> <updated>2026-09-09T17:19:13+09:00</updated> <id>https://jinsanpark.github.io/posts/Embedding-Project-12/</id> <content type="text/html" src="https://jinsanpark.github.io/posts/Embedding-Project-12/" /> <author> <name>JinsanPark</name> </author> <category term="Project" /> <category term="newsFinder" /> <summary>지난 시간 지난번에 이제 L1에 동시 요청이 들어오면 안 고장나게 만든다고 했죠. 그전에, 왜 그런지, 어떻게 박살나는지 부터 알아 봅시다. 왜? LinkedHashMap로 Lru 만들었는데, 이거는 활짝 열린 방입니다. 근데 일인실이에요. 한명만 들어와서 일하고 나가야 합니다. 두명 들어오면 서로 할일 하다가 동선 겹치고 일 꼬이고 그래요. 동시 요청을 그러면 한번 보내고, 어떤 문제가 발생하는지 한번 봅시다. 저는 먼저 에이전트로 동시 요청 보내보니, 막상 별 문제가 없었습니다. 29.472 exec-6 total_ms=0.0304 29.475 exec-7 total_ms=0.0131 정확히는 동시에 요청이 아니라 3ms차이에다가 작업이 0.03ms라서 테스트를 만들기로 방향...</summary> </entry> </feed>
