[메모/스크랩] 캐시메모리 기법

https://wikidocs.net/65523

https://zion830.tistory.com/46

https://velog.io/@lxxjn0/%EB%B0%98%EB%B3%B5%EC%A0%81%EC%9C%BC%EB%A1%9C-%EC%82%AC%EC%9A%A9%EB%90%98%EB%8A%94-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4-%EC%BA%90%EC%8B%B1%ED%95%98%EA%B8%B0

 

 

https://aws.amazon.com/ko/caching/

 

 

캐싱이란 무엇이고 어떻게 작동합니까 | AWS

 

캐싱(Caching)이란

캐싱을 알아보기 전에 캐시의 사전적인 정의를 알아보자.

캐시(cache)는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다 - wikipedia

캐싱은 이러한 캐시라는 작업을 하는 행위(행동)이다.

캐싱은 컴퓨터 분야에서 다양하게 사용된다. CPU에서도 성능 향상을 위해 사용되고 메모리, 웹 페이지를 동작시키는 분야까지 분야를 가리지 않고 사용된다.

그럼 이번에 소개할 반복적으로 사용되는 인스턴스 캐싱하기란 어떤 상황을 말하는 것일까? Java Wrapper Class의 캐싱을 예시로 살펴보도록 하자.

Java Wrapper Class

Java에서는 Primitive Type을 Reference Type으로 사용하기 위해 만든 Wrapper Class가 있다.

Java의 Wrapper Class로는 Byte, Short, Integer, Long, Float, Double, Character, Boolean, Void가 있다.

기존에 Primitive Type이 존재하는데 굳이 Wrapper Class를 만든 이유는 무엇이고, 언제 사용될까?

코드를 작성할 때 다양한 라이브러리를 활용하게 된다. Java에서는 다양한 라이브러리들을 제공하는데, 이를 사용하기 위해서는 객체 타입이 필요한 경우가 발생한다.

가장 간단한 예시로 JCF(Java Collection Framework)의 List를 사용하는 코드를 확인해보자.

package lotto.domain;

import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public class WrapperTest {
    public static void main(String[] args) {
        List<int> primitiveList = new ArrayList<>(); // error!
        List<Integer> wrapperList = new ArrayList<>(); // good!
    }
}

List를 사용할 때는 List의 타입을 명시해주기 위해 Generic<T> 을 사용한다. 그런데 Generic 안에 들어가는 값으로는 객체만 가능하기 때문에 int와 같은 Primitive Type을 사용하면 에러가 발생하게 된다. Primitive 값인 int를 사용하기 위해서는 이를 감싼 Wrapper Class를 활용하여 List를 사용할 수 있다. int뿐 아니라 다른 Primitive Type 역시 다양한 라이브러리와 프레임워크의 활용을 위해 Wrapper Class를 제공한다.

또한 Wrapper Class는 객체이기 때문에 null값이 들어올 수 있다. Primitive type들은 기본 값을 가지고 있기 때문에 값을 할당하지 않을 경우 null이 아니라 기본값을 가지도록 한다(int의 경우 0이 기본값이다).

만약 Java를 이용한 웹 서비스에서 Request나 Response용 객체를 다룬다면 값이 존재하지 않는 경우 null을 할당해줘야 한다. 그러나 Primitive Type을 사용하는 경우 기본 값이 할당되면서 의도하지 않은 결과를 야기할 수도 있다.

Wrapper Class는 이런 상황에서 적절하게 사용하는 것이 좋다.

Wrapper Class에서의 값 비교

인스턴스는 각각의 주소를 가진다. 그렇다면 Wrapper Class로 생성한 값(인스턴스)들은 서로 다른 주소값을 가지기 때문에 실제 값을 비교하기 위해 오버라이딩이 된 equals() 를 사용하리라 생각할 수 있다.

이러한 추측이 맞는지 확인하기 위해 Test를 한 번 진행해보았다.

import static org.assertj.core.api.Assertions.*;

import org.junit.jupiter.api.Test;

public class IntegerTest {
    @Test
    void test1() {
        Integer num1 = 1;
        Integer num2 = 1;

        assertThat(num1.equals(num2)).isTrue();
    }

    @Test
    void test2() {
        Integer num1 = 1;
        Integer num2 = 1;

        assertThat(num1 == num2).isTrue();
    }
}

첫 번째 테스트의 경우 우리가 추측한 데로 equals() 가 오버라이딩 되어 있다면 true가 나와야 한다. 그리고 두 번째 테스트의 경우 서로 다른 인스턴스이기 때문에 false가 나올 것이다.

하지만 결과는 둘 다 true이다.

Integer는 Wrapper Class 인스턴스이므로 서로 다른 주소를 가져야 하는데 동일한 주소를 가지고 있다. 이러한 일이 가능한 이유는 캐싱 덕분이다.