인프런 커뮤니티 질문&답변
작성한 질문수
Proxy Mode 객체 관련 문의드립니다.
작성
·
253
2
안녕하세요. 항상 좋은 답변 주셔 감사합니다.
Proxy Mode 객체 관련 문의드릴 것이 있어 질문글을 적습니다.
영한님께서 강의 중에 Proxy Mode 객체는 계속 생성이 되니, 싱글톤 스코프처럼 사용 시 문제가 발생할 수 있으니 주의를 해야한다고 말씀을 해주셨는데... 조금 헷갈려서.. 관련해서 질문드리고 싶습니다.
1. Proxy Mode를 사용했을 때, CGLIB를 활용한 빈 객체는 스프링 컨테이너가 생성될 때 최초로 단 한 번만 생성된다. 프록시 객체가 호출되면, 호출될 때 마다 진짜 객체를 만든다.
위의 내용처럼 이해를 하는 것이 맞을까요? 그리고 싱글톤 스코프처럼 사용 시 문제가 발생할 수 있다는 것은 프록시 객체는 단 한번 생성되나, 진짜 객체는 매번 생성되고 소멸되니 그것에 대한 COST가 비싸다는 것으로 이해를 하면 될까요?
2. 이 강의해서 사용된 REQUEST 스코프의 동작 방식이 궁금합니다. 사용된 코드 동작방식을 보면 HTTP REQUEST가 들어오면 REQUEST SCOPE 객체를 만들고 나갈 때까지객체를 유지하고, 나간다면 다음으로 들어온 HTTP REQUEST를 입력받아서 동작하는 것처럼 보입니다.
즉, 항상 HTTP REQUEST SCOPE 객체는 스프링 컨테이너에 하나만 존재하는 것처럼 보입니다.
그런데 예를 들어 정말 동시에 HTTP REQUEST가 들어오면, 어떻게 동작하는지 알 수 있을까요? 동시에 들어오면 HTTP REQUEST SCOPE 빈이 스프링 컨테이너에 다수 개가 생성될 것 같아서... 기존에 컨트롤러와 서비스가 동작하던 것처럼 동작하지 않을 것 같습니다.
항상 좋은 답변 달아주셔서 감사합니다.
답변 2
1
안녕하세요. ...님, 공식 서포터즈 David입니다.
.
1. Proxy Mode를 사용했을 때, CGLIB를 활용한 빈 객체는 스프링 컨테이너가 생성될 때 최초로 단 한 번만 생성된다. 프록시 객체가 호출되면, 호출될 때 마다 진짜 객체를 만든다. 위의 내용처럼 이해를 하는 것이 맞을까요? 그리고 싱글톤 스코프처럼 사용 시 문제가 발생할 수 있다는 것은 프록시 객체는 단 한번 생성되나, 진짜 객체는 매번 생성되고 소멸되니 그것에 대한 COST가 비싸다는 것으로 이해를 하면 될까요?
=> 프록시 객체가 호출될 때마다 진짜 객체를 매번 생성할지는 말지는 프록시 객체가 알고 있는 진짜 빈의 스코프에 따라 달라집니다. 싱글톤 빈처럼 사용되는 것이 프록시 객체의 장점이지만 그 뒤에서 실제 동작하는 방식은 스코프(Request, Singleton, Protorype 등)에 따라 달리지기 때문에 싱글톤처럼 사용시 문제가 발생할 수 있다는 것입니다.
2. 이 강의해서 사용된 REQUEST 스코프의 동작 방식이 궁금합니다. 사용된 코드 동작방식을 보면 HTTP REQUEST가 들어오면 REQUEST SCOPE 객체를 만들고 나갈 때까지객체를 유지하고, 나간다면 다음으로 들어온 HTTP REQUEST를 입력받아서 동작하는 것처럼 보입니다. 즉, 항상 HTTP REQUEST SCOPE 객체는 스프링 컨테이너에 하나만 존재하는 것처럼 보입니다. 그런데 예를 들어 정말 동시에 HTTP REQUEST가 들어오면, 어떻게 동작하는지 알 수 있을까요? 동시에 들어오면 HTTP REQUEST SCOPE 빈이 스프링 컨테이너에 다수 개가 생성될 것 같아서... 기존에 컨트롤러와 서비스가 동작하던 것처럼 동작하지 않을 것 같습니다.
=> 스코프는 객체가 아니라 빈의 라이프 사이클 범위를 말하는 것입니다. 특정 빈의 스코프가 Request라면 사용자 요청이 서버에 들어올 때마다 빈이 생성되고 요청이 다 처리되면 소멸됩니다. 따라서 다수의 요청이 들어왔을 때 Request 스코프인 빈을 호출하게 되면 각 요청별로 빈이 생성되어 사용됩니다.
.
감사합니다.
0
싱글톤처럼 사용 시 문제가 될 수 있다는 부분의 좀 더 정확한 것이 무엇인지 알려주실 수 있으실까요? 프록시 객체는 어찌되었건 필요한 시점에는 객체가 만들어져 있어, 프로그램 동작 과정에서 문제가 없는 것으로 알고 있습니다.
예를 들어 프록시 객체의 진짜 객체가 싱글톤이라고 했을 때, 싱글톤처럼 사용하는 것은 문제가 없을 것입니다. 프록시 객체의 진짜 객체가 Request 스코프라고 가정하면, 매번 프록시 객체를 호출할 때 마다, 객체를 생성하고 반환해주기 때문에 객체를 생성하는데 많은 비용이 들 것입니다. 그런데 이를 싱글톤 객체라고 착각하고 개발자가 그렇게 설계를 할 경우, 이런 비용 관점에서 문제가 있다고 보는 것이 타당할까요?
말씀하신 '싱글톤처럼 사용 시 문제가 될 수 있다는 것'이의 간단한 예라도 하나 알려주시면 너무 감사드리겠습니다.
=> (상태를 가지지 않는) 싱글톤을 사용하는 이유 중 하나는 멀티스레드 환경에서 객체 재사용성을 높이기 위함입니다. 억지스러울 수 있지만 예를 들어보자면 엄청나게 많은 요청이 쏟아질 때 싱글톤처럼 보이는 프록시 객체를 호출했습니다. 그런데 프록시 객체가 뒤에서 호출한 건 프로토타입 스코프를 가지는 빈이었던 겁니다. 그러면 수많은 빈이 생성될테고 이는 서버에 불필요한 부하를 주게 될 것입니다. 원래 의도는 싱글톤 빈인 줄 알고 열심히 호출했었던 것이니깐요.
==> 다수의 요청이 들어오면, 각 요청 별로 빈이 생성되어 사용된다는 것은 이해를 하고 있습니다. 질문이 정확하지 못한 점 죄송합니다. 이렇게 질문드리는것이 제 질문 의도와 맞는 것 같습니다.
ClientA가 Http request를 요청하고, Controller에서 해당 request를 처리하고 있는 상황입니다. 이 때, ClientB에서 Http Request를 요청이 또 들어옵니다. 이 때, ClientA의 http 요청은 반환이 되지 않은 상황입니다. 이런 상황이라면 ClientB의 Request 스코프 객체는 ClientA의 Http 요청이 끝나서 완료될 때까지 생성이 연기될까요? 아니면, ClientA의 요청과는 별개로 ClientB의 Request 스코프 객체가 생성되어 스프링 컨테이너에 관리가 될까요?
=> 이미 알고 계신 것 같습니다. 각 요청(request)별로 빈이 생성되고 컨테이너에 의해 관리됩니다.
3. 한 가지 추가 질문이 있습니다! 혹시 이런 프록시 모드로 생성되는 객체는 스프링 컨테이너가 생성될 때, 단 한번 생성된다고 이해를 하면 될까요?
=> 네, 프록시 객체는 한 번만 생성됩니다.
답변 감사드립니다. 위에 답변 달아주신 내용에 대해서 추가 질문 드릴 것이 있습니다. 답변 달아주시면 너무 감사드리겠습니다!
1. Proxy Mode를 사용했을 때, CGLIB를 활용한 빈 객체는 스프링 컨테이너가 생성될 때 최초로 단 한 번만 생성된다. 프록시 객체가 호출되면, 호출될 때 마다 진짜 객체를 만든다. 위의 내용처럼 이해를 하는 것이 맞을까요? 그리고 싱글톤 스코프처럼 사용 시 문제가 발생할 수 있다는 것은 프록시 객체는 단 한번 생성되나, 진짜 객체는 매번 생성되고 소멸되니 그것에 대한 COST가 비싸다는 것으로 이해를 하면 될까요?
=> 프록시 객체가 호출될 때마다 진짜 객체를 매번 생성할지는 말지는 프록시 객체가 알고 있는 진짜 빈의 스코프에 따라 달라집니다. 싱글톤 빈처럼 사용되는 것이 프록시 객체의 장점이지만 그 뒤에서 실제 동작하는 방식은 스코프(Request, Singleton, Protorype 등)에 따라 달리지기 때문에 싱글톤처럼 사용시 문제가 발생할 수 있다는 것입니다.
==> 싱글톤처럼 사용 시 문제가 될 수 있다는 부분의 좀 더 정확한 것이 무엇인지 알려주실 수 있으실까요? 프록시 객체는 어찌되었건 필요한 시점에는 객체가 만들어져 있어, 프로그램 동작 과정에서 문제가 없는 것으로 알고 있습니다.
예를 들어 프록시 객체의 진짜 객체가 싱글톤이라고 했을 때, 싱글톤처럼 사용하는 것은 문제가 없을 것입니다. 프록시 객체의 진짜 객체가 Request 스코프라고 가정하면, 매번 프록시 객체를 호출할 때 마다, 객체를 생성하고 반환해주기 때문에 객체를 생성하는데 많은 비용이 들 것입니다. 그런데 이를 싱글톤 객체라고 착각하고 개발자가 그렇게 설계를 할 경우, 이런 비용 관점에서 문제가 있다고 보는 것이 타당할까요?
말씀하신 '싱글톤처럼 사용 시 문제가 될 수 있다는 것'이의 간단한 예라도 하나 알려주시면 너무 감사드리겠습니다.
2. 이 강의해서 사용된 REQUEST 스코프의 동작 방식이 궁금합니다. 사용된 코드 동작방식을 보면 HTTP REQUEST가 들어오면 REQUEST SCOPE 객체를 만들고 나갈 때까지객체를 유지하고, 나간다면 다음으로 들어온 HTTP REQUEST를 입력받아서 동작하는 것처럼 보입니다. 즉, 항상 HTTP REQUEST SCOPE 객체는 스프링 컨테이너에 하나만 존재하는 것처럼 보입니다. 그런데 예를 들어 정말 동시에 HTTP REQUEST가 들어오면, 어떻게 동작하는지 알 수 있을까요? 동시에 들어오면 HTTP REQUEST SCOPE 빈이 스프링 컨테이너에 다수 개가 생성될 것 같아서... 기존에 컨트롤러와 서비스가 동작하던 것처럼 동작하지 않을 것 같습니다.
=> 스코프는 객체가 아니라 빈의 라이프 사이클 범위를 말하는 것입니다. 특정 빈의 스코프가 Request라면 사용자 요청이 서버에 들어올 때마다 빈이 생성되고 요청이 다 처리되면 소멸됩니다. 따라서 다수의 요청이 들어왔을 때 Request 스코프인 빈을 호출하게 되면 각 요청별로 빈이 생성되어 사용됩니다.
==> 다수의 요청이 들어오면, 각 요청 별로 빈이 생성되어 사용된다는 것은 이해를 하고 있습니다. 질문이 정확하지 못한 점 죄송합니다. 이렇게 질문드리는것이 제 질문 의도와 맞는 것 같습니다.
ClientA가 Http request를 요청하고, Controller에서 해당 request를 처리하고 있는 상황입니다. 이 때, ClientB에서 Http Request를 요청이 또 들어옵니다. 이 때, ClientA의 http 요청은 반환이 되지 않은 상황입니다. 이런 상황이라면 ClientB의 Request 스코프 객체는 ClientA의 Http 요청이 끝나서 완료될 때까지 생성이 연기될까요? 아니면, ClientA의 요청과는 별개로 ClientB의 Request 스코프 객체가 생성되어 스프링 컨테이너에 관리가 될까요?
3. 한 가지 추가 질문이 있습니다! 혹시 이런 프록시 모드로 생성되는 객체는 스프링 컨테이너가 생성될 때, 단 한번 생성된다고 이해를 하면 될까요?
좋은 답변 감사드립니다!