안 평범한 개발자의 하루

List

Set

Queue

Map

정렬 알고리즘 비교

자료구조별 비교

참고 Big O 그래프

public class ExComparator {
	public static void main(String[] args) {
		Pair[] arr = new Pair[10];
		List<Pair> list = new ArrayList<Pair>();
		
		for(int i=0; i<10; i++) {
			int a = (int)(Math.random()*10);
			int b = (int)(Math.random()*10);
			arr[i] = new Pair(a, a+b);
			list.add(arr[i]);
		}
		
		// 정석 Comparator 객체사용 (With array)
		// 오른쪽객체가 왼쪽으로올경우 오름차순
		// 반대는 내림차순
		Arrays.sort(arr, new Comparator<Pair>() {
			@Override
			public int compare(Pair o1, Pair o2) {
				return o2.min - o1.min;
			}
		});
		
		System.out.println("원본");
		System.out.println(list.toString());
		System.out.println();
		
		//2가지 항목비교
		Collections.sort(list, new Comparator<Pair>() {
			public int compare(Pair o1, Pair o2) {
				int first = o2.min - o1.min;
				int second = o2.max - o1.max;
				return first != 0? first : second;
			}
		});
		System.out.println("2개항목비교");
		System.out.println(list.toString());
		System.out.println();
		
		//람다사용 With list (Collections)
		Collections.sort(list, (o1, o2) -> o1.min - o2.min);
		System.out.println("람다로 한개만비교");
		System.out.println(list.toString());
		System.out.println();
		
		
		//Stream 사용
		List<?> sorted = list.stream()
			.sorted((o1,o2) -> o2.min - o1.min)
			.collect(Collectors.toList());
		System.out.println("Stream 사용");
		System.out.println(sorted.toString());
		System.out.println();
		
	}
}

class Pair {
	int min;
	int max;
	
	Pair(int min, int max) {
		this.min = min;
		this.max = max;
	}
	
	@Override
	public String toString() {
		return String.format("[%d, %d]", min,max);
	}
}

Garbage Collector

 가비지컬렉터란 JVM에서 실행되는 프로그램으로, Application 내부에서 사용되지 않는 객체를 제거한다. 이게무슨말일까?? 다음소스를 한번 봐보자.

for (File f : files) {
    String s = f.getName();
}

 이 소스코드는 files의 길이에 따라 달라지겠지만, files의 length가 2개 이상일경우, 계속해서 String 객체를 생성한다. 이는 계속해서 메모리를 String객체를 만들기위해 할당하고있다.

 그러나 2번째 반복에서는 첫번째 만들어진 String s 객체를 사용하지않는다. 이것을 "Garbage" 라고 간주한다. 이런 Garbage가 쌓이고 쌓이게 된다면, 새로운 객체를 만들 공간이 부족해질 것이다. 이를 위해 Garbage Collector가 있는 것이다.

any live threads or by any static references 에서 도달할수 없는 Object의 경우, Garabage Collection 의 적격의 대상이다.

 즉 개체의 모든참조가 null일경우 Garbage Collection의 대상이 될수있다.
 또한 A -> B 의 의존성이있고, B -> A의 의존성이있지만, A와 B가 다른 reference가 없을경우 A와 B 모두 수거대상이된다.

Heap Generations for Garbage Collection

 자바의 Object는 Heap에서 생성되며,힙은 GC를 위해 3개의 parts로 나뉘어져있다. 각각 Young(New) generation, Tenured(Old) Generation and Perm Area 이다.

 Young Generation은 더 나아가, Eden Space, Survivor1과 Survivor2로 나뉜다. Object가 맨처음 생성되었을때, 그것은 Eden공간 내부에서 생성되고, 그 후 Minor Garbage Collection후 살아남은 객체는 S0으로 이동하고, 또 Minor GC가 있은후 S1으로 이동된다. 만약 Major garbage collection 전에 s0,s1 영역에 계속 살아남았다면, 이것은 Old(tenured) 영역으로 이동하게된다.

 또한 Heap의 Perm 공간에는 메서드, Classes와 String Pool 및 Class level detail 에대한 Metadata를 저장하는곳이다.

Major GC가 Minor GC보다 느린이유.

- 예를들어가정해보자 15개의 objects 들을 s1 영역으로 이동시키고, 다음 gc에서는 s2로 이동시킨다. 또 다음 GC는 survivor를 s1 또는 s2로 이동시킬것이다. 이렇게 되면 계속해서 살아남은 생존자들은 old generation으로 이동하게 될것이다.

- Major GC는 old generation에 free space가 없어 더이상 survive한 객체를 옮길수 없을때에 발생한다. old generation에 모든 object에 대해 gc가 수행된다. old generation은 보통 young generation보다 많은 object를 담고있기때문에, GC처리가 훨씬 오래걸린다. 

what is? 

minor gc: 모든 새로운객체는 Young Generation에 할당되는데, Young Generation이 꽉차게되면 이는 minor GC를 일으킴.
major gc: Young generation에 있는 객체에 임계값을 설정하고, 그 임계값이 넘게되면 Old gerneration으로 이동되게된다. 그리고 쌓이고 쌓이게되다보면, Old Generation영역도 GC가 발동되게 되는데 이를 Major GC라고한다. 종종 live Object도 수집대상이 되기때문에, 훨씬 더 느리다.
full gc: Perm 영역에는 클래스 및 메소드가 사용되는데 설명하는 metadata들이 포함되어있다. 사용중인 클래스를 기준으로 JVM에 의해 채워진다. 또한 java SE 클래스또한 이곳에 저장될수있다. JVM이 기존것들이 더이상 필요하지않고, 다른클래스를 위한 공간이 필요하다고 여겨질때 perm 영역가지 포함되어 gc가 일어나게되는데 이를 full gc라고한다.
String Pool:
method,classes, class level metadata

!!!주의: JDK 8에서는 Perm Gen이 Heap에서 삭제되고, Native 영역에 MetaData Space가 생겼다.

Java 7의 JVM 구조

<----- Java Heap ----->             <--- Native Memory --->
+------+----+----+-----+-----------+--------+--------------+
| Eden | S0 | S1 | Old | Permanent | C Heap | Thread Stack |
+------+----+----+-----+-----------+--------+--------------+
                        <--------->
                       Permanent Heap
S0: Survivor 0
S1: Survivor 1

JAVA 8의 JVM 구조

<----- Java Heap -----> <--------- Native Memory --------->
+------+----+----+-----+-----------+--------+--------------+
| Eden | S0 | S1 | Old | Metaspace | C Heap | Thread Stack |
+------+----+----+-----+-----------+--------+--------------+

(Heap 영역은 JVM에 의해 관리된 영역이며, Native 메모리는 OS 레벨에서 관리하는 영역으로 구분된다)

Perm 영역은 보통 Class의 Meta 정보나 Method의 Meta 정보, Static 변수와 상수 정보들이 저장되는 공간으로 흔히 메타데이터 저장 영역이라고도 한다. 이 영역은 Java 8 부터는 Native 영역으로 이동하여 Metaspace 영역으로 변경되었다. (다만, 기존 Perm 영역에 존재하던 Static Object는 Heap 영역으로 옮겨져서 GC의 대상이 최대한 될 수 있도록 하였다)

왜 Perm이 제거됐고 Metaspace 영역이 추가된 것인가?

최근 Java 8에서 JVM 메모리 구조적인 개선 사항으로 Perm 영역이 Metaspace 영역으로 전환되고 기존 Perm 영역은 사라지게 되었다. Metaspace 영역은 Heap이 아닌 Native 메모리 영역으로 취급하게 된다. (Heap 영역은 JVM에 의해 관리된 영역이며, Native 메모리는 OS 레벨에서 관리하는 영역으로 구분된다) Metaspace가 Native 메모리를 이용함으로서 개발자는 영역 확보의 상한을 크게 의식할 필요가 없어지게 되었다.

JAVA7과 JAVA8의 변동사항.

Perm 영역에 있던 것들은 어디로?

 - Mehtods of a class -> Native 영역으로
 - Names of the clases -> Native 역역으로
 - Constant pool information (String 포함) -> Heap 영역으로
 - Static Variable -> Heap 영역으로

JDK8에 관한내용 출처:https://johngrib.github.io/wiki/java8-why-permgen-removed/

전체출처: https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

https://stackoverflow.com/questions/24592834/why-major-garbage-collection-is-slower-than-minor

JDK 8 로 넘어오면서 레가시 시스템의 성능저하를 MaxMetaspaceSize를 바꿔서 튜닝사례

https://brunch.co.kr/@heracul/1

Java진영에서 어느날 갑자기 등장하여 개발자들을 모호하게 만들어 버렸던
POJO!!

이 녀석이 당췌 뭐야?
많은 사람들은 그럴싸한 이론으로 POJO를 포장하려 한다.
실제 강의나 책을 통해서 설명되는 POJO는 이해하기 힘듬. ㅜㅜ

본인 또한 처음 POJO란 용어를 접했을때 이게 뭐지? 
직역하면 명백히 오래된 자바 객체?

아쒸 명백히 오래된 자바객체가 한두개야?
jdk 1.0 버전때 부터 제공되던 수 많은 클래스들을 통해 생성하는 객체들이 그럼 다 POJO야?

POJO는 2000년 9월에 열린 컨퍼런스(어떤 컨퍼런스인지는 모름)에서
Rebecca Parsons, Josh MacKenzie, Martin Fowler 가 처음 사용한 용어이다.

다른 개념 다 버리고

POJO = Java Beans
여기서 Java Beans는 Sun의 Java Beans나 EJB의 Bean을 뜻하는것이 아닌
순수하게 setter, getter 메소드로 이루어진 Value Object성의 Bean을 말한다.

예를 들면 아래와 같다.

우리가 열심히 코딩하거나 이클립스를 통해 자동으로 생성하던
그 깡통 빈 클래스!! 를 통해서 생성된 객체!
맞다 바로 이것이 POJO 다.

그럼 왜 이전 부터 사용하던 Beans라고 말하지 않고
사람들 헤깔리게 POJO 새로이 불렀을까?

이유인즉, Beans라는 용어로 위의 깡통 빈 클래스를 정의하기에는
Java Beans나 EJB의 Beans와 구분이 모호하고 또한 Beans라는 용어로
정의되는 여타 다른 개념들과의 확실한 분리를 위해
POJO라는 용어를 사용한것이라 볼 수 있다.

=========================================================================================

-- 쉽게 따라하는 자바 웹 개발 중 --

POJO라는 용어는 평범한 자바 객체라는 뜻인데 어떤 객체를 평범하다고 지칭하는지

그리고 POJO를 사용해서 개발하는게 왜 중요한지 설명 한다. 

먼저 평범하다고 말하는 객체는 다음과 같은 특징. 

• 클래스 상속을 강제하지 않는다. 
• 인터페이스 구현을 강제하지 않는다. 
• 애노테이션 사용을 강제하지 않는다.

POJO가 아닌 대표적인 객체

public HelloServlet extends HttpServlet{ ... } 

자바 서블릿 코드를 작성할 때는 이렇게 반드시 HttpServlet을 상속바아야 한다. 

서블릿 프로그래밍을 한다는 이유로 객체지향 프로그래밍의 핵심적인 기능 중 하나인 상속을 빼앗긴 것이나 마찬가지이다. 코드를 작성하고 있는 개발자가 직접 상속을 사용할 수 있는 기회가 없어졌으니.. 

그리고 extends HttpServlet이 추가되면서 이 코드를 이해하기 어려워 진다. 

HttpServlet에서 어떤 기능을 제공하는지 어떤 코드를 어떻게 재사용해야 할지 판단하기도 어렵다. 

POJO는 그러한 제약이 없는 일반적인 객체를 말한다. 

상속이나 인터페이스 구현을 사용하지 않은 객체를 말하는 것이 아니라, 그런 것을 라이브러리나 프레임워크로부터 강제받지 않는 객체라는 것이다. 

public HelloController { .... } 

이런 클래스라면 개발자의 선택에 따라 자신이 만든 다른 Controller클래스를 상속받게 하거나 인터페이스를 구현하게 할 수 있다. 또한 이해하기 쉬운 코드이기도 하다. 무엇보다도 이런 객체가 테스트를 작성하기 편하다. 테스트를 작성하기 쉬운 코드가 곧 좋은 코드이다. 

POJO는 자바 표준 스펙이 아니다.