캐시에 A가 있는지 확인했다면, 새 자료를 넣어도 A가 남을까요? Java의 LinkedHashMap을 ‘최근 접근 순서’로 설정한 종이 모형을 만들어 봐요. A의 값은 10, B의 값은 20이고 처음에는 A, B 순서로 넣었어요.
[A,B]는 가장 오래 접근한 키부터 가장 최근 키까지의 순서예요. 새 키를 넣은 직후 개수가 2를 넘으면 맨 앞 한 개를 지우는 정책을 따로 정해요. 초기 용량을 2로 설정했다는 뜻은 아니에요. 다른 처리나 동시에 일어나는 작업은 없어요.
같은 시작 목록을 두 장 만들어 봐요. 첫 장에서는 get(A)로 값을 읽고, 둘째에서는 containsKey(A)로 존재 여부만 확인해요. 첫 답은 10, 둘째는 참이에요. 공식 규칙에서 get은 접근으로 세지만 containsKey는 세지 않아요. 그래서 첫 목록은 [B,A]로 바뀌고 둘째는 [A,B]로 남아요.
이제 두 목록 모두 새 C를 값 30과 함께 맨 뒤에 넣어 볼게요. 각각 [B,A,C]와 [A,B,C]입니다. 3>2이므로 첫 항목 하나를 지우면 [A,C]와 [B,C]가 돼요.
G와 K는 각각 값을 읽은 뒤, 존재만 확인한 뒤의 목록 변화를 나타내요. P_C는 C를 넣고 초과 항목을 지우는 처리예요. 앞 결과를 다음 입력으로 보내는 합성으로 쓰면 다음과 같아요.
A는 첫 목록에만 남아요. 두 번 모두 “A가 있다”는 사실을 확인했지만 같은 삭제 결과는 아니에요. 교사는 지워질 이름을 먼저 묻고, 최근 접근으로 인정되는 동작에 표시하게 해요.
착안: Oracle, Java SE 26의 LinkedHashMap. 알려진 API에 자체 두 항목 제한을 적용한 종이 추적 사례이며 실제 실행·캐시 성능을 측정한 자료가 아니에요.