• 자바에서 컬레션 프레임워크이란, 다수의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 방법을 제공하는 클래스의 집합을 의미한다. 다시 말해 데이터를 저장하는 자료 구조와 데이터를 처리하는 알고리즘을 구조화하여 클래스로 구현해 놓은 것이다.

• JDK 1.2 이전까지는 Vector, Hashtable, Properties와 같은 컬렉션 클래스들을 서로 각자 다른 방식으로 처리해야 했으나 JDK 1.2부터 컬렉션 프레임웍이 등장하면서 다양한 종류의 컬렉션 클래스가 추가되고 모든 컬렉션 클래스를 표준화된 방식으로 다룰 수 있도록 체계화되었다.

• 이러한 컬렉션 프레임워크은 자바의 인터페이스(interface)를 사용하여 구현된다.

• 컬렉션 프레임워크에서는 크게 컬렉션을 3가지 타입으로 나누어 핵심이 되는 주요 인터페이스를 정의했다.

1. List 인터페이스
2. Set 인터페이스
3. Map 인터페이스

• 여기서 List와 Set 인터페이스의 공통점을 뽑아내어 새로운 인터페이스인 Collection을 추가로 정의하였다.
• Map 인터페이스는 구조상의 차이로 인해 별도로 정의된다. 후에 컬렉션 프레임워크의 실세 소스를 분석해보면 객체지향적인 설계능력을 향상시키는데 많은 도움이 될 것이다.

자바에서 컬렉션 프레임워크를 구성하고 있는 인터페이스 간의 상속 관계는 다음 그림과 같다.

• 위의 그림에서 나 <K, V>는 컬렉션 프레임워크를 구성하는 모든 클래스가 제네릭으로 표현되어 있다는 것을 알려준다.

• 순서가 있는 데이터의 집합으로, 데이터의 중복을 허용한다.
• 예) 대기자 명단
• Vector, ArrayList, LinkedList, Stack, Queue 등

• 순서가 없는 데이터의 집합으로, 데이터의 중복을 허용하지 않는다.
• 예) 양의 정수집합, 소수의 집합
• HashSet, TreeSet 등

• 키(Key)와 값(Value)의 한 쌍으로 이루어진 데이터의 집합으로 순서가 없다.

• 키는 중복을 허용하지 않지만 값은 중복될 수 있다.

• 예) 우편번호, 지역번호(전화번호) HashMap, TreeMap, Hashtable, Properties

• 컬렉션 프레임워크에 속하는 인터페이스를 구현한 클래스를 컬렉션 클래스(Collection Class)라고 한다. (즉 위의 List, Set, Map 3가지 중에 하나를 구현하고 있음.) 구현한 인터페이스의 이름이 클래스의 이름에 포함되어 있어서 이름만으로도 클래스의 특징을 쉽게 알 수 있도록 되어있다.

(Vector, Stack, Hashtable, Properties와 같은 클래스들은 컬레션 프레임워크가 만들어지기 전에 존재하던 것이기 때문에 컬렉션 프레임워크의 명명법을 따르지 않음, Vector나 Hashtable과 같은 기존의 컬렉션 클래스들은 호환을 위해서 남겨두었지만 가능하면 사용하지 않는 것이 좋다. 그 대신 새로 추가된 ArrayList와 HashMap을 사용하자)

Call by value

Call by value와 Call by reference의 설명으로 자주 등장하는 swap 예제입니다.

일단 먼저 예제를 보겠습니다.

Class CallByValue{
		public static void swap(int x, int y) {
				int temp = x;
				x = y;		
				y = temp;
		}

		public static void main(String[] args) {
				
				int a = 10;
				int b = 20;
		
				System.out.println("swap() 호출 전 : a = " + a + ", b = " + b);
				swap(a, b);
				System.out.println("swap() 호출 후 : a = " + a + ", b = " + b);
		
		}
}

결과는 어떻게 나올까요?

swap() 호출 전 : a = 10, b = 20

swap() 호출 후 : a = 10, b = 20

"어? 분명 swap() 메서드에 a, b를 넘겼으니까 값이 바껴야 하는거 아냐?"

네, 아닙니다. 결론을 먼저 말씀드리자면 swap() 메서드 호출 시에 사용한 인자 a, b와 swap() 메서드내의 매개변수 x, y는 서로 다르기 때문입니다.

아래 그림을 보시면 이해가 빠르게 되실겁니다.

main()에서 선언 된 변수 a와 b가 각각 메모리의 0x0001번지와 0x0005번지에 할당 되었다고 가정합니다. 할당 된 메모리 변수에는 각각 10과 20의 값이 저장됩니다. 이후, swap() 메서드 호출 시에 사용한 인자 a와 b는 할당 된 메모리 주소가 아닌 메모리에 담겨져 있던 값만이 복사되어 swap() 메서드 내부의 매개변수 x와 y의 메모리 주소에 담겨지게 됩니다. 당연하게도 swap() 메서드가 수행하는 동안 사용되는 변수들은 main()에 존재하는 a와 b가 아닌 swap() 내부에 새로 생성 된 x와 y이기 때문에 메서드 수행 후에도 결과 값에 변화가 없습니다.

장황하게 설명한 것 같지만, 요점은 다음과 같습니다.

Call by value는 메서드 호출 시에 사용되는 인자의 메모리에 저장되어 있는 값(value)을 복사하여 보낸다.

Call by reference

Call by reference는 메서드 호출 시에 사용되는 인자가, 값이 아닌 주소(Address)를 넘겨줌으로써, 주소를 참조(Reference)하여 데이터를 변경할 수 있습니다.

이번에도 위와 비슷한 예제를 보도록 하겠습니다.

Class CallByReference{
		int value;

		CallByReference(int value) {
				this.value = value;
		}

		public static void swap(CallByReference x, CallByReference y) {
				int temp = x.value;
				x.value = y.value;
				y.value = temp;
		}

		public static void main(String[] args) {
				CallByReference a = new CallByReference(10);
				CallByReference b = new CallByReference(20);
				
				System.out.println("swap() 호출 전 : a = " + a.value + ", b = " + b.value);
				swap(a, b);
				System.out.println("swap() 호출 전 : a = " + a.value + ", b = " + b.value);
		
		}

}

결과는 다음과 같습니다.

swap() 호출 전 : a = 10, b = 20

swap() 호출 후 : a = 20, b = 10

이번에는 원하는 대로 a와 b의 값이 바뀌어서 잘 나왔습니다.

그림을 보며 설명하도록 하겠습니다.

main()에서 선언 된 CallByReference 타입의 변수 a와 b는 각각 객체를 생성하여 0x0001번지와 0x0005번지에 저장된 10과 20의 주소 값을 저장하게 됩니다. 이후, swap() 메서드 호출 시에 인자 a와 b는 메모리에 저장 된 주소 값을 복사하여 매개변수 x와 y의 메모리에 저장합니다. 결국 swap() 메서드는 10과 20이 저장 된 0x0001번지와 0x0005번지의 주소를 참조하여 연산하기 때문에, 연산 결과에 따라 원본 데이터가 변하게 됩니다. main()에서 선언 된 변수 a와 b는 각각 0x0001번지와 0x0005번지를 가리키고 있기 때문에 변한 데이터를 불러들여 결과 값이 변하게 됩니다.

Call by reference는 메서드 호출 시 사용되는 인자 값의 메모리에 저장되어있는 주소(Address)를 복사하여 보낸다.

• AspectJ는 PARC에서 개발한 자바 프로그래밍 언어용 관점 지향 프로그래밍 (AOP) 확장 기능이다.

• 이클립스 재단 오픈 소스 프로젝트에서 독립형 또는 이클립스로 통합하여 이용 가능하다.

• AspectJ는 최종 사용자를 위한 단순함과 이용성을 강조함으로써 폭넓게 사용되는 AOP에 대한 디 팩터 표준(사실 상 표준)이 되었다.

• AspectJ란 순수 Spring AOP API에서 제공하지 않는 필드에 대한 Advisor를 지원하고, CTW, LTW과 같은 다양한 위빙 방법을이용할 수 있는 기능을 제공하여 프로그램의 퍼포먼스를 향상 시킬 수 있도록 해준다.

• 또한 @Aspect 어노테이션을 바탕으로 Aspect 로직을 작성 할 수 있어 기존의 xml방식보다는 더 편리하다.

• 현재는 Spring AOP + AspectJ는 거의 표준이라고 할 정도로 많이 사용이 되고 있는 추세다.

• AspectJ는 스프링 뿐만 아니라 AOP를 지원하지 않는 프레임 워크에서도 AOP를 지원할 수 있도록 도움을 주는 API이다.

• Aspect란 객체지향 언어의 클래스와 비슷한 개념이라고 생각하면 이해하기 쉽다.

• 그 자체로 애플리케이션의 도메인 로직을 담은 핵심기능은 아니지만, 많은 오브젝트에 걸쳐서 필요한 부가기능을 추상화 해놓은 것이다.

• 구조적으로 보자면 Aspect = PointCut + Advisor이다.

• 위빙(Weaving) 이란? Aspect 클래스에 정의 한 Advice 로직을 타깃(Target)에 적용하는 것을 의미한다.
• 위빙 방법으로는 RTW, CTW, LTW 3가지가 있다.

• Spring AOP에서 사용하는 위빙 방식이다. Proxy를 생성하여 실제 타깃(Target) 오브젝트의 변형없이 위빙을 수행한다.
• 실제 런타임 상, Method 호출 시에 위빙이 이루어 지는 방식이다.
• 소스파일, 클래스 파일에 대한 변형이 없다는 장점이 있지만, 포인트 컷에 대한 어드바이스 적용 갯수가 늘어 날수록 성능이 떨어진다는 단점이 있다.
• 또한 메소드 호출에 대해서만 어드바이스를 적용 할 수 있다.

• AspectJ에는 AJC (AspectJ Compiler)라는 컴파일러가 있는데 Java Compiler를 확장한 형태의 컴파일러이다. (AspectJ에서 사용하는 방식)
• AJC를 통해 java 파일을 컴파일 하며, 컴파일 과정에서 바이트 코드 조작을 통해 Advisor 코드를 직접 삽입하여 위빙을 수행한다.
• 장점으로는 3가지 위빙 중에서는 가장 빠른 퍼포먼스를 보여준다. (JVM 상에 올라갈 때 메소드 내에 이미 advise 코드가 삽입 되어있기 때문)
• 하지만 컴파일 과정에서 lombok과 같이 컴파일 과정에서 코드를 조작하는 플러그인과 충돌이 발생할 가능성이 아주 높다. (거의 같이 사용 불가)

• 스프링의 AOP는 우리가 사용했던 기법들을 활용한 프록시 방식의 AOP와 AspectJ를 사용하여 프록시를 쓰지 않는 AOP 기술이 있다.
• 그렇다면 어떻게 프록시 없이 부가기능을 타깃 오브젝트에 적용해 줄 수 있을까?
• AspectJ는 프록시처럼 간접적인 방법이 아니라, 타깃 오브젝트를 뜯어고쳐서 부가기능을 직접 넣어주는 직접적인 방법을 사용한다.(컴파일 위빙)
• 컴파일된 타깃의 클래스 파일 자체를 JVM에 로딩되는 시점을 가로채서 바이트코드로 조작하는 복잡한 방법을 사용한다.
• 즉, 트랜잭션 코드가 비즈니스 로직과 함께 있었을 때처럼 만들어버린다. 왜 프록시를 사용하지 않고 이러한 방법을 사용할까?

1. 바이트코드를 조작해 타깃 오브젝트를 직접 수정해버리면 DI 컨테이너의 도움을 받아 프록시를 생성하지 않고 AOP를 적용할 수 있기 때문이다.
2. 프록시 방식보다 훨씬 강력하고 유연한 AOP가 가능하기 때문이다.

• 프록시를 사용하면 대상이 메소드로 제한되지만 바이트코드를 직접 조작하면 오브젝트의 생성, 필드 값의 조회와 조작, 스태틱 초기화 등의 다양한 부가기능을 수행할 수 있다.
• 타깃 오브젝트가 생성되는 순간에도 작업이 가능하다.
• AspectJ같은 고급 기술을 사용하기 위해 별도의 바이트코드 컴파일러, 클래스 로더를 사용해야 하는 번거로움이 필요하다.
• 따라서 대부분은 프록시 방식의 스프링 AOP로도 충분하다.

출처: https://haviyj.tistory.com/33 [What do you want?]

• Spring에서 POJO(plain, old java object)를 ‘Beans’라고 부른다.
• Beans는 애플리케이션의 핵심을 이루는 객체이며, Spring IoC(Inversion of Control) 컨테이너에 의해 인스턴스화, 관리, 생성된다.
• Beans는 우리가 컨테이너에 공급하는 설정 메타 데이터(XML, class 설정 파일)에 의해 생성된다.
• 컨테이너는 이 메타 데이터를 통해 Bean의 생성, Bean Life Cycle, Bean Dependency(종속성) 등을 알 수 있다.
• 애플리케이션의 객체가 지정되면, 해당 객체는 getBean() 메서드를 통해 가져올 수 있다.

• 일반적으로 XML, class 파일에 정의한다. 주요 속성
• class(필수): 정규화된 자바 클래스 이름
• id: bean의 고유 식별자
• scope: 객체의 범위 (sigleton, prototype)
• constructor-arg: 생성 시 생성자에 전달할 인수
• property: 생성 시 bean setter에 전달할 인수
• init method와 destroy method

• 스프링은 기본적으로 모든 bean을 singleton으로 생성하여 관리한다.
• 구체적으로는 애플리케이션 구동 시 JVM 안에서 스프링이 bean마다 하나의 객체를 생성하는 것을 의미한다.
• 그래서 우리는 스프링을 통해서 bean을 제공받으면 언제나 주입받은 bean은 동일한 객체라는 가정하에서 개발을 한다.
• request, session, global session의 Scope는 일반 Spring 어플리케이션이 아닌, Spring MVC Web Application에서만 사용된다. 참고

• ‘singleton’ bean은 Spring 컨테이너에서 한 번 생성된다.
• 컨테이너가 사라질 때 bean도 제거된다.
• 생성된 하나의 인스턴스는 single beans cache에 저장되고, 해당 bean에 대한 요청과 참조가 있으면 캐시된 객체를 반환한다.
• 즉, 하나만 생성되기 때문에 동일한 것을 참조한다.
• 기본적으로 모든 bean은 scope이 명시적으로 지정되지 않으면 singleton이다.

• ‘prototype’ bean은 모든 요청에서 새로운 객체를 생성하는 것을 의미한다.
• 즉, prototype bean은 의존성 관계의 bean에 주입 될 때 새로운 객체가 생성되어 주입된다.
• 정상적인 방식으로 gc에 의해 bean이 제거된다.

• 상태가 없는 공유 객체: 상태를 가지고 있지 않은 객체는 동기화 비용이 없다. 따라서 매번 이 객체를 참조하는 곳에서 새로운 객체를 생성할 이유가 없다. 읽기용으로만 상태를 가진 공유 객체: 1번과 유사하게 상태를 가지고 있으나 읽기 전용이므로 여전히 동기화 비용이 들지 않는다. 매 요청마다 새로운 객체 생성할 필요가 없다.
• 공유가 필요한 상태를 지닌 공유 객체: 객체 간의 반드시 공유해야 할 상태를 지닌 객체가 하나 있다면, 이 경우에는 해당 상태의 쓰기를 가능한 동기화 할 경우 싱글톤도 적합하다.
• 쓰기가 가능한 상태를 지니면서도 사용빈도가 매우 높은 객체: 애플리케이션 안에서 정말로 사용빈도가 높다면, 쓰기 접근에 대한 동기화 비용을 감안하고서라도 싱글톤을 고려할만하다. 이 방법은 1. 장시간에 걸쳐 매우 많은 객체가 생성될 때, 2. 해당 객체가 매우 작은 양의 쓰기상태를 가지고 있을 때, 3. 객체 생성비용이 매우 클 때에 유용한 선택이 될 수 있다.

• 쓰기가 가능한 상태를 지닌 객체: 쓰기가 가능한 상태가 많아서 동기화 비용이 객체 생성 비용보다 크다면 싱글톤으로 적합하지 않다.
• 상태가 노출되지 않은 객체: 일부 제한적인 경우, 내부 상태를 외부에 노출하지 않는 빈을 참조하여 다른 의존객체와는 독립적으로 작업을 수행하는 의존 객체가 있다면 싱글톤보다 비싱글톤 객체를 사용하는 것이 더 나을 수 있다.

https://gmlwjd9405.github.io/2018/11/10/spring-beans.html