개발공부블로그

finalize() 메소드란?

JVM이 메모리 누수를 방지하기위해 실행하는 GC가 수행될 때 더 이상 사용하지 않는 자원에 대한 정리작업을 할 때 호출하는 메소드. 이러한 종료자의 치명적인 단점이 있다. 

바로 즉시 실행되리라는 보장이 전혀 없다는 것.

종료자의 문제점은 이 뿐만이 아니다.

 일반적으로는 uncaught 예외가 던져지면 스레드는 종료되고 StackTrace가 표시되지만, 종료자 안에서는 아니다. 경고문 조차 발생하지 않는다..

또한, 종료자를 사용하면 프로그램 성능이 심각하게 떨어진다. (객체 메모리 해제 등의 이유로..)

그럼 자원의 반환 / 삭제는 어떻게?

정말 정말 종료자는 쓸 곳이 없는 녀석인가..!? ( 이것도 1번 빼고 딱히..?)

1. 명시적 종료 메서드 호출을 잊을 경우에 대비하는 안전망의 역할. 종료자는 그런 자원을 발견하게 될 경우 반드시 경고 메세지를 로그로 남겨서 코드가 잘못되어있음을 알려야 한다.

2.네이티브 피어와 연결된 객체를 다룰 때 사용될 수도 있다. 

3.하위 클래스에서 상위 클래스 종료자를 재정의 하면서 상위 클래스 종료자 호출을 잊으면, 상위 클래스 종료자는 절대 호출되지 않는다. 따라서 아래와 같이 처리할 수 있다.

C/C++처럼 직접 메모리 관리를 해야하는 언어와 달리, GC가 포함된 언어를 사용하면 프로그래밍이 아주 편해진다. 

 위의 코드는 기능상 문제는 없으나, 메모리 누수 문제가 있다. 이 메모리 누수는 과연 코드의 어느 부분에서 생길까? 메모리누수는 바로

기능적으로 동일한 객체는 필요한 때마다 만드는 것보다 재사용하는 편이 낫다. 절대로 피해야 하는 극단적인 예.

생성자 대신 정적 팩터리 메서드를 이용하면 불필요한 객체 생성을 피할 수 있을 경우가 많다. 생성자는 호출할 때마다 새 객체를 만들지만, 정적 팩터리 메서드는 그럴 필요도 없고 실제로 그러지도 않을 것이기 때문이다.

 또 한가지 예를들면, 아래와 같은 베이비붐 세대의 사람인지 판별하는 메서드가 있다고 치자. 

 위 코드의 문제점은 무엇일까? sum이 long이 아니라 Long으로 선언되어 있는데 , 그 덕에 Integer.MAX_VALUE의 수만큼 Long객체가 생성되는 문제점이다. 객체 표현형 대신 기본 자료형을 사용하고, 생각지도 못한 자동객체화가 발생하지 않도록 유의해야 한다.

 그러나 객체를 만드는 비용이 높으니 무조건 피하라는 것이 아니고, 객체를 만들어서 코드의 명확성과 단순성을 높이고 프로그램의 능력을 향상시킬 수 있다면, 일반적으로는 만드는 것이 좋다.

 마찬가지로, 직접 관리하는 객체 풀을 만들어서 객체 생성을 피하는 기법은 객체 생성 비용이 극단적으로 높지 않다면 사용하지 않는 것이 좋다. 객체 풀을 만드는 비용이 정당화 될 만한 객체의 예로 가장 고전적인 것은 데이터베이스 연결이다.

때로는 정적 메서드나 필드만 모은 클래스를 만들고 싶을 때가 있다. 자바의 기본 자료형 값 또는 배열에 적용되는 메서드를 한군데에 모아 두는 클래스라던가, 정적 메서드를 모아둔 클래스 등등 이러한 유틸리티 클래스들은 객체를 만들 목적의 클래스가 아니다. 하지만 생성자를 생략하면 컴파일러는 자동으로 기본생성자를 만들어 버린다. 따라서 원래 의도와는 달리 객체가 생성되어 버리는 것이다.

해결방법. private 생성자를 클래스에 넣어서 객체 생성을 방지

싱글턴은 객체를 하나만 만들 수 있는 클래스다. 싱글턴은 보통 유일할 수 밖에 없는 시스템 컴포넌트를 나타낸다. 

싱글턴 구현방법1

 Elvis.getInstance는 항상 같은 객체에 대한 참조를 반환한다. 팩터리 메서드를 사용하는 방법의 장점은 

장점1. API를 변경하지 않고도 싱글턴 패턴을 포기할 수 있다는 것. return INSTANCE 대신 new Elvis(); 로 바꿔주면 API 변경없이 싱글턴 패턴을 포기할 수 있다.

장점2.제네릭 타입을 수용하기 쉽다

Enum을 이용한 실글턴 구현

 이 접근법은 기능적으로 public 필드를 사용하는 구현법과 통일하다. 한가지 차이는 좀 더 간결하는 것과, 직렬화가 자동으로 처리된다는 것.

요약

원소가 하나뿐인 enum자료형이야 말로 싱글턴을 구현하는 가장좋은 방법이다.

정적 팩터리나 생성자는 같은 문제를 갖고 있다. 선택적 인자가 많은 상황에 잘 적응하지 못한다는 것. 예를들면, 영양 성분표를 나타내는 클래스가 있는 필수적인 항목은 몇가지 되지 않는다. 총 제공량 , 1회 제공량 , 1회 제공량당 칼로리 정도? 그러나 선택적인 항목은 엄청나게 많다. 지방함량율 , 나트륨 함량, 콜레스테롤 함량 등등.. 이러한 항목을 어떻게 표현할 수 있을까?

점층적 생성자 패턴

자바빈 패턴

생성자에 전달되는 인자 수가 많을 때 적용 가능한 두 번째 대안이다. 인잔 없는 생성자를 호출하여 객체부터 만든 다음, 설정 메서드를 호출하여 필수 필드뿐 아니라 선택적 필드의 값들까지 채우는 것.

 그러나 자바빈 패턴에는 심각한 단점이 있다. 1회의 함수 호출로 객체 생성을 끝낼 수 없으므로, 객체 일관성이 일시적으로 깨질 수 있다.생성자의 인자가 유효한지 검사하여 일관성을 보장하는 단순한 방법을 여기서는 사용할 수 없다. 

   책에는 위와같이 적혀있는데 , 아래과 같이 인자가 유효한지 검사할 수 있지 않나..? 아마 책의 의도는 생성자 한곳에서 검사하지 않는 다는 말인 것같음.. 

 그리고 자바빈패턴에서는 변경 불가능한 클래스(생성자가 private)를 만들 수 없다.

빌더 패턴

클래스를 통해 객체를 만드는 일반적인 방법은 public으로 선언된 생성자를 이용하는 것이다. 또한 클래스에 public으로 선언된 정적 팩터리 메서드를 이용하여 객체를 생성하는 방법도 있다. 정적 팩터리 메서드를 이용했을 때 장단점은 아래와 같다.

장점1. 정적 팩터리 메서드에는 이름이 있다.

장점2. 호출할 떄마다 새로운 객체를 생성할 필요가 없다.

장점3. 반환값 자료형의 하위 자료형 객체를 반환할 수 있다.

위와 같은 방식으로 코드를 작성하면, SubA클래스의 구현 세부사항을 감출 수 있다. 

장점4. 형인자 자료형 객체를 만들 떄 편리하다.

단점1. 정적 팩터리 메서드만 있는 클래스를 만들면 생기는 가장 큰 문제는, public이나 protected로 선언된 생성자가 없으므로 하위 클래스를 만들수가 없다.

단점2. 정적 팩터리 메서드는 다른 정적 메서드와 확연히 구분되지 않는다.

요약

가변 비트레이트 스트리밍

어떻게?

그렇다면 사용자는 파일이 이렇게 쪼개져 있다는 것을 어떻게 알 수 있을까? 가변 비트레이트 스트리밍이 시작되는 시점에 사용자의 플레이어는 인코딩된 파일들의 조각 정보가 담겨 있는 메니페스트파일을 받게 되고 이 파일을 담고 있는 비트레이트의 종류, 부분 파일의 식별 방법에 따라 적절한 파일을 HTTP로 요청하여 받게 된다.

[가변 비트레이트 전송 프로토콜의 종류]

-MPEG_DASH(Dynamic Adaptive Streaming over HTTP)

-Adobe Dynamic Streaming for Flash(HDS)

-Apple Http Adaptive Streaming for iPhone/iPad/STB (HLS)

-Microsoft Smooth Streaming

출처 : https://ondemand.tistory.com/177