답변

Kotlin은 프로퍼티의 getter 및 setter에 inline 수정자를 붙일 수 있게 해줍니다. 이것은 컴파일러가 접근자 코드를 호출 위치에 직접 인라인(삽입)하여 성능을 최적화할 수 있는 권한을 부여합니다.

예시:

val foo: Int
    inline get() = expensiveCalculation()

인라인 덕분에 getter 함수는 호출 비용이 발생하지 않으며(예: 루프 내에서) 접근자 코드가 짧은 경우 성능 저하가 없습니다.
인라인은 상태가 없는(stateless) getter에만 가능하며, 모든 로직에 대해 인라인이 허용되는 것은 아닙니다.
reified generic 매개변수나 크로스 링크가 있는 람다 식이 포함된 setter/getter에는 inline을 사용할 수 없습니다.

최고의 실천 방법: 부작용이 없는 매우 짧고 자주 호출되는 표현식에 대해서만 인라인 접근자를 사용하세요.

인라인 getter/setter가 있는 프로퍼티에 리플렉션이 있는 주석을 추가하면(KProperty를 통해 사용할 경우) 인라인이 작동합니까?

답변: 아닙니다. 프로퍼티가 리플렉션 API를 통해 사용되거나 KProperty를 참조하는 경우, 컴파일러는 getter/setter를 인라인으로 삽입할 수 없으며, 이는 일반 메서드로 남습니다. 인라인은 코드에서 직접 접근할 때만 발생합니다.

이야기

리플렉션으로 인한 성능 손실:

핫 프로퍼티를 인라인 getter로 변경하여 불필요한 호출을 제거하려고 했습니다. 나중에 KProperty를 통해 유효성을 검사하는 것을 추가했더니, 결국 호출이 리플렉션을 통해 이루어져서 인라인 접근자의 장점이 완전히 사라졌습니다.

이야기

인라인 시의 원치 않는 부작용:

인라인 getter가 로깅을 수행했습니다:

inline get() {
    println("accessed!")
    return field
}

이런 구현으로 인해 프로퍼티가 코드의 여러 부분에서 자주 읽히면서 예상치 못한 로깅이 발생하여 로그가 심하게 지저분해졌습니다.

이야기

인라인 프로퍼티 변경으로 인한 ABI 파손:

라이브러리에서 인라인 getter의 로직을 변경했지만 종속 모듈을 다시 컴파일하지 않았습니다. 클라이언트는 이전 서명을 계속 사용했으며 — 확장된 ABI와 인라인이 결합되어 호환성 문제가 발생하고 클라이언트가 업데이트 시 숨겨진 실패가 발생했습니다.

Kotlin에서 인라인 프로퍼티 접근자(인라인 getter 및 setter)는 어떻게 작동합니까? 사용 시 어떤 특징과 주의 사항이 있으며, 성능에 어떤 영향을 미치고 예상치 못한 오류가 발생할 수 있는 곳은 어디입니까? 예를 들어주세요.