도커란? 도커는 리눅스 컨테이너를 기반으로 하는 오픈소스 프로젝트다. 네임스페이스, 컨트롤 그룹과 같은 리눅스 커널 기능을 이용해서 운영체제 위에 컨테이너들을 생성하고 이를 사용하여 애플리케이션을 생성, 배포 및 실행하도록 설계된 도구 OS, 백엔드 프로그램, 데이터베이스, 메시지 큐 등 무엇이든 컨테이너로 추상화할 수 있게 해줌 도커가 주목받은 이유 - 간편한 사용법, 속도, 도커 허브, 모듈성과 확장성 더보기 간편한 사용법: 도커는 개발자, 시스템 관리자, 아키텍트 등 누구든지 컨테이너의 이점을 이용해서 손쉽게 이동성 있는 애플리케이션을 생성, 테스트 할 수 있도록 만들어졌다. 누구든 애플리케이션을 자신의 랩탑에서 간단히 패키징하고, 공용 클라우드, 개인용 클라우드, 혹은 bear metal에서 보존..

가상화는 "기술" 클라우드 컴퓨팅은 가상화 기술을 기반으로 한 "서비스" 1. 가상화 더보기 가상화가 등장하기 이전에 기업의 전통적인 방식은 하나의 서버에 하나의 운영체제, 하나의 프로그램을 운영하여 각 서버가 갖고 있는 시스템 자원 중 약 50~70% 정도만 사용할 수 있었다. 즉, 물리적 서버가 갖고 있는 성능을 100% 활용해서 사용할 수 없었다. 이 과정에서 기업은 갖고 있는 물리적 서버를 최대한 효율적으로 사용하길 원했고, 각 서버가 100%의 성능을 발휘할 수 있길 원했다. 즉, 한 대의 물리적인 장비를 마치 여러 대의 장비처럼 활용하거나, 여러 장비를 하나의 장비처럼 묶어서 사용하기를 원했고 이로 인해 등장한 기술이 "가상화"이다. 1.1. 가상화의 개념 - 가상화(Virtualization..

Effective Java 3/E 아이템8:finalizer와 cleaner 사용을 피하라 1. 자바의 두 가지 객체 소멸자 finalizer(deprecated) - 예측할 수 없고 상황에 따라 위험할 수 있음. ( 일반적으로 불필요함. ) - 오동작, 낮은 성능, 이식성 문제의 원인이 되기도함 cleaner - Java 9 에서 finalizer 대안으로 소개된 API - finalizer 보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 불필요하다. 2. finalizer와 cleaner 사용을 피해야하는 이유 a. finalizer와 cleaner는 수행 시점 및 수행 여부에 대한 보장이 없다. - 수행 시점이 GC 알고리즘에 달려있음, 구현방식에 따라 다름. - finalizer 쓰레드..

Effective Java 3/E 아이템7: 다 쓴 객체 참조를 해제하라 1. 메모리 누수 해결은 다 쓴 참조를 null 처리하자 GC가 다 쓴 객체를 알아서 회수하기 때문에 메모리 신경을 쓰지 않아도 된다고 오해할 수 있다. class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object object) { ensureCapacity(); elements[size++] = object; } pub..

Effective Java 3/E 아이템6: 불필요한 객체 생성을 피하라 똑같은 기능의 객체를 매번 생성하기 보다는 객체 하나를 재사용 하는편이 좋을 때가 많다. String.matches() 는 정규표현식으로 문자열 형태를 확인하기 가장 쉬운 방법이다. public static void main(String[] args) throws Exception { String num = "VI"; if (isRomanNumeral(num)) { ... } ... } static boolean isRomanNumeral(String s) { return s.matches("^M{0,4}(CM|CD|D?C{0,3})(XC|XL|L?X{0,3})(IX|IV|V?I{0,3})$"); } } matches() 내부에서 ..

Effective Java 3/E 아이템5: 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 클래스들이 자원(다른 클래스)에 의존하는 경우가 있다. 예를 들어서 SpellChecker라는 클래스에서 dictionary라는 유틸리티 클래스를 사용한다고 가정해보겠다. 1. 정적 유틸리티 클래스 public class SpellChecker { private static final Lexicon dictionary = ...; private SpellChecker() {} // 인스턴스화 방지 (아이템 4 참고) public static boolean isVaild(String word) {...} public static List suggestions(String typo) {...} } //사용은 이..

Effective Java 3/E 아이템4: 인스턴스화를 막으려거든 private 생성자를 사용하라 우리는 Java로 어떠한 프로젝트를 개발할 때에 정적 메서드만 담은 Util 클래스를 만들곤한다. 하지만 여태까지의 나는 Util 클래스의 생성자를 구현하지 않았다. Util 클래스의 생성자를 구현하지 않으면, 컴파일러는 자동으로 기본 생성자를 만든다. 이러한 경우에 의도치 않게 Util 클래스의 객체가 생성될 수 있게 된다. 그렇다면 Util 클래스의 객체를 생성할 수 없게 하려면 어떻게 해야할까? 우리는 그 답을 이미 알고 있다. 싱글톤 패턴에서 우리는 하나의 객체를 제외한 객체가 생성되지 않도록 private 생성자 함수를 만든다. 이처럼 JDK에 내장되어 있는 Arrays, Collections와 ..

Effective Java 3/E 정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋겠다. 그렇다고 하더라도 정적 팩터리를 사용하는게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자! 아이템3: 생성자나 열거 타입으로 싱글턴임을 보증하라 싱글턴? 인스턴스를 오직 하나만 생성할 수 있는 클래스 싱글턴을 만드는 방식 1. public static final 필드 방식 2. static factory method 방식 3. 원소가 1개인 ENUM 타입 1. public static final 필드 방식의 싱글턴 생성자는 private으로 감춰두고, 유일한 인스턴스에 접근할 수 있는 수단을 public static ..

Effective Java 3/E 정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋겠다. 그렇다고 하더라도 정적 팩터리를 사용하는게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자! 아이템2: 생성자에 매개변수가 많다면 빌더를 고려하라 Class 설계시 필수, 선택적으로 받을 매개변수가 구분됩니다. 이렇게 설계된 다향한 형태의 클래스들을 객체화하는 대표적인 3가지 패턴이 존재합니다. 1. 점층적 생성자 패턴 ( Telescoping Constructor Pattern ) 2. 자바 빈즈 패턴 ( Java Beans Pattern ) 3. 빌더 패턴 ( Builder Pattern ) 1. 점층적 생성자 패턴..