
두 개념은 메서드 호출 시 인자를 해당 메서드 내부로 전달하는 방법을 의미합니다.
call by value는 메서드에 인자를 전달 시, 인자로 전달할 값을 복사하여 메서드 내에서 사용하는 것을 말합니다. 이로 인해 메서드 내에서 변수의 값을 변경 하더라도 원래의 값은 변경되지 않습니다.
call by reference는 메서드에 변수를 전달 시, 객체의 참조값(메모리 주소)이 전달되는 것을 말합니다. 해당 참조값을 전달하여 참조하고 있는 메모리 내 값을 변경할 경우 실제 값이 변경됩니다.
💡 꼬리 질문
Java에서는 어떻게 사용되고 있나요?
자바에서는 오직 Call by value로만 동작하게 됩니다.
즉, 자바 내에서 참조값을 인자로 전달하는 듯하게 보이는 것들은 사실 인자를 통해서 복사된 참조값을 전달하기 때문에 해당 참조 변수는 이전에 호출한 곳에서 사용한 변수와 다른 변수입니다.
단지, 같은 참조값을 가지고 있기 때문에 서로에게 영향을 미칠 수는 있습니다.
즉, 메서드를 호출하는 곳에서 인자로 들어가는 값과 메서드 내에서 사용된 변수는 Stack 영역에서 서로 다르게 존재하는 변수입니다.
Override는 메서드의 재정의를 의미하며, Overload는 메서드 시그니처를 다르게 하여, 동일한 메서드명을 여러 개 사용할 수 있도록 해주는 것을 말합니다.
조금 더 자세히 설명하면 다음과 같습니다.
Override는 상속관계 또는 추상-구현체 관계에서 상위 클래스/인터페이스에 정의 또는 구현된 메서드를 하위 클래스에서 재정의하는 것을 말합니다.
Overload는 메서드명은 같지만, 메서드 파라미터의 갯수, 순서, 데이터 타입이 다르다면 동일한 이름의 메서드를 여러 개 정의할 수 있는 것을 말합니다.
JPA가 필요한 경우는 다음과 같습니다.
반면에 JPA가 필요없는 경우는 다음과 같습니다.
JPA에서 지원하는 기능으로 find()로 반환된 엔티티 객체에 값을 변경해주는 것만으로 update 쿼리가 발생하는 것을 말합니다.
JPA는 1차 캐시에 각 엔티티마다 스냅샷을 함께 저장하며, 해당 스냅샷의 상태와 비교하여 다를 경우, update 쿼리를 쓰기 지연 SQL 저장소에 저장됩니다. 이는 커밋되는 시점에 해당 update 쿼리가 DB에 반영됩니다.
Java Virtual Machine을 말하며, 플랫폼으로부터 독립적으로 java 파일을 실행하기 위해서 필요한 가상 머신입니다.
이전의 C 언어는 각 플랫폼마다 다른 컴파일러를 보유하고 있었기 때문에, 윈도우에서 작업한 C 언어 프로그램이 리눅스 환경에서 실행을 위해서는 리눅스 전용 컴파일러로 컴파일 해준 뒤 실행해줘야 됐습니다.
하지만, Java는 각 플랫폼 위에 JVM이 있어, java 소스 파일을 바이트코드(class 파일)로 컴파일 해주면, 어떤 플랫폼에서든 코드 실행이 가능하게 됩니다.
💡 JDK의 구성요소에 대해 설명해주세요
JVM의 구조는 크게 "컴파일 타임 환경"과 "런타임 환경"으로 구분됩니다.
컴파일 타임 환경에서는 자바 소스 코드를 바이트 코드로 컴파일 해주는 영역을 말합니다. 해당 환경에서 동작하는 자바 컴파일러는 정적 컴파일러(javac)입니다.
런타임 환경에서는 다음과 같이 구성되어 있습니다.
자바의 컴파일 과정은 다음과 같습니다.
자바 소스코드를 작성합니다.
자바 컴파일러(javac)에 의해 바이트코드로 번역합니다.
바이트 코드를 클래스 로더에 전달합니다.
클래스 로더는 프로그램 실행에 필요한 클래스들을 동적으로 런타임 데이터 영역에 로딩합니다.
토큰 기반 인증 방식은 http 프로토콜의 무상태성을 위해 토큰 내 회원 정보를 서명을 통해 암호화하여 저장해줌으로써, 서버에서는 인증 처리를 위해 어떠한 데이터에 관여하지 않고 토큰을 통해서만 인증이 이뤄지도록 해주는 방식을 말합니다.
토큰 인증 방식 중 대중적으로 사용되는 라이브러리 중 하나가 JWT 입니다.
토큰 인증 방식의 취약점은 탈취의 위험이 있습니다. 이로 인해, 토큰의 유효 기간을 최대한 짧게 설정하는 방식을 채택하게 됩니다.
하지만, 위의 해결책은 사용자의 잦은 로그인 횟수로 인해 사용자 경험이 떨어지게 됩니다.이를 해결하기 위해서 인증용으로 사용되는 토큰과 해당 토큰을 재사용할 수 있도록 refresh 용도로 사용되는 토큰을 구분하여 사용하도록 했습니다.
이를 통해서 접근용 토큰의 유효 시간이 만료되면, 재발급 토큰으로 검증하여 접근용 토큰을 재발급해줌으로써 사용자 경험을 향상시켜주기 때문입니다.
하지만, 이러한 방식에도 불구하고, 아직 만료되지 않은 accessToken이 탈취될 경우, 해당 토큰으로 인증과정을 통과할 수 있다는 점과 refreshToken이 탈취될 수 있다는 위험이 있습니다.
해당 문제들에 대해서는 도메인과 개발자의 성향에 따라 트레이드 오프를 따져 다르게 구현될 수 있습니다.