📑 문제 설명
지도개발팀에서 근무하는 제이지는 지도에서 도시 이름을 검색하면 해당 도시와 관련된 맛집 게시물들을 데이터베이스에서 읽어 보여주는 서비스를 개발하고 있다.
이 프로그램의 테스팅 업무를 담당하고 있는 어피치는 서비스를 오픈하기 전 각 로직에 대한 성능 측정을 수행하였는데, 제이지가 작성한 부분 중 데이터베이스에서 게시물을 가져오는 부분의 실행시간이 너무 오래 걸린다는 것을 알게 되었다.
어피치는 제이지에게 해당 로직을 개선하라고 닦달하기 시작하였고, 제이지는 DB 캐시를 적용하여 성능 개선을 시도하고 있지만 캐시 크기를 얼마로 해야 효율적인지 몰라 난감한 상황이다.
어피치에게 시달리는 제이지를 도와, DB 캐시를 적용할 때 캐시 크기에 따른 실행시간 측정 프로그램을 작성하시오.
- 캐시 교체 알고리즘은 LRU(Least Recently Used)를 사용한다.
- cache hit일 경우 실행시간은 1이다.
- cache miss일 경우 실행시간은 5이다.
🧑🏻💻 나의 풀이
import java.util.LinkedList;
import java.util.Queue;
class Solution {
public int solution(int cacheSize, String[] cities) {
int answer = 0;
int hit = 1;
int miss = 5;
if(cacheSize==0) {
return answer = cities.length*5;
}
String[] citiesLow = new String[cities.length];
for(int i=0;i<cities.length;i++) {
citiesLow[i] = cities[i].toLowerCase();
}
Queue<String> que = new LinkedList<>();
for(int i=0;i<citiesLow.length;i++) {
if(que.contains(citiesLow[i])) {
answer += hit;
que.remove(citiesLow[i]);
que.add(citiesLow[i]);
} else {
if(que.size()==cacheSize) {
answer += miss;
que.poll();
que.add(citiesLow[i]);
} else {
answer += miss;
que.add(citiesLow[i]);
}
}
}
return answer;
}
}캐시 교체 알고리즘이 LRU라는 것을 보고 FIFO 구조인 Queue로 배열을 사용했다.
- 대소문자 구분을 하지 않도록 toLowerCase()로 citiesLow에 소문자 도시 이름을 담는다.
- if: que에 도시 이름이 포함된다면 answer(총 실행시간) += hit, 존재하는 값을 remove()로 삭제 후 add() 맨 뒤에 추가한다.
else: que에 도시 이름이 포함되지 않다면 answer += miss, 값을 add() 맨 뒤에 추가한다. 만일 que.size()가 cacheSize와 같다면 poll() 맨 앞의 값을 출력한 후 추가한다.
7,17번 문제만 틀리길래 이유가 뭔가 싶었다.
알고보니 cacheSize가 0일 때 cities에 ["LA", "LA"]와 같이 중복값이 있는 경우, 캐시크기가 0이라 값이 저장되지 않기 때문에 cache miss로 10초의 시간이 걸린다.
하지만 내가 작성한 코드에 값을 넣으면 값이 que.contains()로 처리돼 6초가 나왔던 것이다.
if(cacheSize==0)로 캐시크기가 0일 때 예외처리를 해주었더니 해결되었다.
💡 학습하기
- LRU
Least Recently Used의 약자로 가장 오랫동안 참조되지 않은 페이지를 교체하는 방식이다.
즉, 페이지를 새로 참조할 때마다 맨 앞에 페이지를 추가하고, 맨 뒤에 있는 페이지가 가장 오랫동안 참조되지 않은 페이지가 된다.
- Cache Hit : 참조하고자 하는 메모리가 캐시에 존재할 경우
- Cache Miss : 참조하고자 하는 메모리가 캐시에 존재하지 않을 경우
🔗 문제 링크
https://school.programmers.co.kr/learn/courses/30/lessons/17680
