코딩 요리사의 레시피

[Effective Java 공부하기] 6. 불필요한 객체 생성을 피하라

devyu — Fri, 1 Apr 2022 01:39:22 +0900

불필요한 객체 생성을 피하라

자바는 기본적으로 사용하지 않는 불필요한 객체를 청소해주는 GC(Garbage Collectotion) 기능이 존재한다만 소스적으로 불변의 객체를 반복적으로 생성하는 것을 최대한 지양해야 한다.

// Boolean 인스턴스를 생성
Boolean b1 = new Boolean(true);

// Boolean 팩터리 메서드를 사용(만들어진 인스턴스를 참조)
Boolean b2 = Boolean.valueOf(true);

위와 같은 불변 객체라면 new Boolean(true) 생성자를 통해 불필요한 객체의 인스턴스를 반복 생성하는 것보다 팩터리 메서드를 사용하여 이미 만들어진 객체의 인스턴스를 재활용하는 것이 더 현명한 선택이 될 수 있을 것 같다.

java.lang.Boolean

실제로 자바9 이후로 new Boolean() 생성자를 통한 Boolean 객체의 인스턴스 추가생성은 deprecated 되어 사용을 자제하라는 공식내용이 있다.

또 다른 예로는 정규표현식을 활용하여 문자열을 체크할 때 주로 사용하는 방식이다. 문자열이 이메일 형식인지 정규표현식을 통해 검증을 하면

private static boolean isEmailPattern(String text) {
    return text.matches("^[a-z0-9_+.-]+@([a-z0-9-]+\\.)+[a-z0-9]{2,4}$");
}

보통 위와 같이 유틸클래스에 정적메서드를 만들어서 사용한다. 실제 나도 회사내부 유틸클래스에서 위와 동일한 코드를 작성한 기억이 있다. 그럼 matches 메서드를 타고 내부로 들어가 보자.

java.util.regex.Pattern

Pattern 팩터리 메서드 내부에서의 동작을 확인하면 regex 패턴을 매개변수로 넘겨 생성자를 통한 Pattern 객체의 인스턴스를 생성한다. 이렇게 생성된 인스턴스는 매번 새롭게 생성되고 곧바로 GC의 대상이 되어 제거된다. (사실 자바의 GC가 일처리가 굉장히 대단해서 왠만한 경우가 아니고서는 큰 성능차이가 없겠지만 알고 쓰는것과 모르는 것은 차이가 많이 나니깐..)

성능을 개선하기 위해서는 불변 객체(Pattern class) 인스턴스를 생성하는것을 정적인 방식으로 딱 한번만 초기화하고 그 다음부터는 재활용 하는 것이다.

// 초기화
private static final Pattern EMAIL_PATTERN = Pattern.compile("^[a-z0-9_+.-]+@([a-z0-9-]+\\.)+[a-z0-9]{2,4}$");


EMAIL_PATTERN.matcher(text3).matches()

로컬 환경에서 인스턴스를 반복 생성하는 방식과 재활용하는 후자 방식의 속도를 체감하고 싶어서 eamil 정규표현식을 1천만번 루프시켰더니 약, 3배 가까이 시간이 절감되는 것을 확인할 수 있었다.

[Effective Java 공부하기] 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

devyu — Thu, 31 Mar 2022 00:46:38 +0900

인스턴스화를 막으려거든 private 생성자를 사용하라

static method와 static field가 존재하는 유틸리티 클래스를 따로 만들어서 사용하곤 한다. 이런 유틸리티 클래스는 인스턴스를 만들어서 사용하려는 목적이 아니기 때문에 인스턴스화를 막아주어야 한다.

클래스는 생성자를 따로 명시해주지 않았다면 컴파일러에 의하여 접근제어자 public을 지닌 기본 생성자가 추가된다. 기본 생성자에 의하여 외부에서 클래스의 인스턴스화 시킬 수 있으니 인스턴스를 막으려거든 기본 생성자를 private 접근제어자로 변경하자.

public class JsonUtils {
    // 외부에서 인스턴스화 되는것을 막는다.
    private JsonUtils() {
    }

}

[Effective Java 공부하기] 2. 생성자에 매개변수가 많다면 빌더를 고려하라

devyu — Tue, 29 Mar 2022 00:12:15 +0900

생성자에 매갭변수가 많다면 빌더를 고려하라

클래스의 인스턴스를 생성하기 위해서 생성자를 이용하는 것이 일반적이다.

Student student = new Student(1L, "장규민", 10);

생성자의 매개변수가 예시처럼 간단할 때는 생성자를 통한 인스턴스 생성 방법은 좋은 선택이 될 수 있지만 10개가 넘는 생성자 매개변수가 존재하고 매개변수의 타입마저 연달아 늘어서 있다면 코드를 작성할 때 휴먼에러로 이러질 수 있다.

특히, 매개변수의 타입이 같아서 개발자가 실수한다면 컴파일 시, 오류를 잡아내지 못하기에 한참동안 방황할 수도 있을 것 같다.

// 매개변수가 많아져 눈에 들어오지 않는다.
Student student = new Student(1L, "장규민", 10, 179, 71, 100, 234, "01099700790", 12034, 634, 1234, 623, 1234, 523, 524);

물론 원하는 속성의 값만 초기화 하기 위해 점층적 생성자 패턴을 사용하여 생성자 매개변수를 줄일수도 있다.

// 초기화를 원하는 속성을 점층적 생성자 패턴
public Student(Long studentId, String name, int height, int weight) {
        this.studentId = studentId;
        this.name = name;
        this.height = height;
        this.weight = weight;
    }


Student student = new Student(1L, "장규민", 179, 71);

하지만 이마저의 매개변수도 길어질 여지는 충분히 있다.

JavaBeans Pattern

생성자 방법의 첫번째 대안으로는 자바빈즈 패턴(JavaBeans pattern)이 있다. 우리가 익숙하게 사용하는 Getter, Setter 메서드를 통해 인스턴스 속성에 접근하고 변경할 수 있다.

public class Student {

    private Long studentId;
    private String name;
    private int age;
    private int height;
    private int weight;
    private String phoneNo;

    public Student() {
    }    

    public Long getStudentId() {
        return studentId;
    }

    public void setStudentId(Long studentId) {
        this.studentId = studentId;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public int getHeight() {
        return height;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getWeight() {
        return weight;
    }

    public void setWeight(int weight) {
        this.weight = weight;
    }

    public String getPhoneNo() {
        return phoneNo;
    }

    public void setPhoneNo(String phoneNo) {
        this.phoneNo = phoneNo;
    }
}

Student s = new Student();
s.setStudentId(1L);
s.setName("장규민");

매개변수가 길게 나열된 생성자 패턴보다는 Setter 메서드를 통해 필요한 속성에 직접 값을 설정할 수 있으므로 직관적으로 보인다. 하지만 Effective Java 에서는 하나의 객체를 만드는데 여러개의 메서드가 호출되어야 하고 객체가 완전히 생성되기 전까지 일관성(consistency)가 무너진 상태로 놓이기에 큰 단점이 될 수 있다고 한다. 이 말은 즉슨 메서드의 호출을 이용한 객체 속성의 설정은 소스 이곳저곳에서 사용될 우려가 있어 런타임 오류 시, 디버깅이 매우 힘든다는 것이다. 때문에 실제로 운영되는 서비스에서는 Setter 메서드의 사용을 최대한 자제하기도 한다.

Builder Pattern

점측적 생성자 패턴의 안전성 + 자바빈즈 패턴의 가독성
불변의 클래스

public class Student {

    private Long studentId;
    private String name;
    private int age;
    private int height;
    private int weight;
    private String phoneNo;

    public Student(Builder builder) {
        studentId = builder.studentId;
        name = builder.name;
        age = builder.age;
        height = builder.height;
        weight = builder.weight;
        phoneNo = builder.phoneNo;
    }

    public static class Builder {

        private Long studentId;
        private String name;
        private int age = 0;
        private int height = 0;
        private int weight = 0;
        private String phoneNo = null;

        public Builder studentId(Long studentId) {
            this.studentId = studentId;
            return this;
        }

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public Builder height(int height) {
            this.height = height;
            return this;
        }

        public Builder weight(int weight) {
            this.weight = weight;
            return this;
        }

        public Builder phoneNo(String phoneNo) {
            this.phoneNo = phoneNo;
            return this;
        }

        public Student builder() {
            return new Student(this);
        }

    }
}

public class Main {
    public static void main(String[] args) {
        // 플루언트(fluent) API 또는 메서드 연쇄(method chaining)
        new Student.Builder()
                .studentId(1L)
                .name("장규민")
                .height(182)
                .weight(120)
                .builder();

    }
}

[JAVA] 정규표현식 정리하기();

devyu — Tue, 29 Jun 2021 22:36:53 +0900

정규표현식(Regular Expression)

- 특정한 규칙을 가진 문자열의 집합을 표현하기 위해 쓰이는 형식언어

기호	설명	예시패턴	매칭문자열
^	문자열 행의 시작	-
$	문자열 행의 끝	-
.	임의의 문자 한 개를 의미(줄바꿈 제외)	[ab].	"ac", "ad", "bb", "bz", etc..
*	앞 표현식의 문자가 없거나 한개 이상을 의미	(car)[0-9]*	"car", "car051", "car421", etc...
+	앞 표현식의 문자가 한개 이상을 의미	(car)[0-9]*	"car0", "car111", etc...
?	앞 표현식의 문자가 없거나 한개를 의미	(car)[0-9]?	"car", "car1", "car4"
[ ]	대괄호는 검증문자 1개를 의미
	a, b, c, d 중 문자 1개	[abcd]	"a", "b", "c", "d"
	b, c 를 제외한 문자 1개	[^bc]	"a", "d", "e", "z", "0", "한"
	a부터 c까지의 문자, e부터 g까지의 문자 1개	[a-ce-g]	"a", "b", "c", "e", "f", "g"
	b부터 e까지의 문자, 1부터 4까지의 문자 1개	[b-e1-2]	"b", "c", "d", "e", "1", "2"
{ }	중괄호는 횟수 또는 범위를 의미	[0-9]{1,3}	"023", "1", "46"
( )	소괄호안의 문자는 그 자체의 의미	(423)	"423"
\|	패턴 안에서 or 연산을 의미	(123\|456\|789)	"123", "456", "789"
\	정규표현식 확장 문자 \ 다음에 일반문자가 오면 특수 문자로 취급 \ 다음에 특수문자가 오면 문자 자체로 취급
\b	단어의 경계
\B	단어의 경계가 아닌 것
\A	입력의 시작 부분
\G	이전 매치의 끝
\Z	입력의 끝이지만 종결자가 있는 경우
\z	입력의 끝
\S	white space가 아닌 문자
\s	white space
\W	한개의 알파벳 or 숫자가 아닌 문자, [^\w]
\w	한개의 알파벳이나 숫자, [a-zA-Z0-9]
\D	한개의 숫자가 아닌 문자, [^0-9]
\d	한개의 숫자, [0-9]
(?i)	대소문자를 구분하지 않음

[Java] 제네릭 타입 정리하기();

devyu — Sun, 25 Apr 2021 23:44:25 +0900

API document을 보다가 제네릭 타입 표현이 많아 이번 기회에 다시 한번 제네릭을 정리하기로 결심하고 오랜만에
자바 책을 다시 펼치게 되었다는...

제네릭은 Java 5에서 처음 등장하였으며,클래스와 인터페이스, 메소드를 정의할 때, 타입을 파라미터로 사용하고, 파라미터는 코드 작성 시 구체적인 타입으로 대체되어 동적인 코드를 생성하도록 도와주는 기술이다.

제네릭 클래스, 제네릭 인터페이스

텍스트로 보면 곧바로 와닿지 않는다. 바로 코드를 보자.

@Getter
public class Height<T> {
    private T t;
}

위 클래스는 간단한 Height 클래스이며, 클래스명 뒤에 제네릭 클래스를 의미하는 <> 부호가 붙어있다. 해당하는 부호 사이에 타입 파라미터를 나타내는 T 문자열이 있으며 일반적으로 대문자 알파벳 한 글자로 표현하곤 한다.

타입 파라미터는 Height 클래스를 실제 코드로 사용할 때, 구체적인 타입을 지정해서 구체화 한다.

public class GenericMain {

    public static void main(String[] args) {

    // 타입 파라미터 Integer
        Height<Integer> heightA = new Height<>();

        // 타입 파라미터 Double
        Height<Double> heightB = new Height<>();

    }

}

변수명 heightA는 타입 파라미터를 Integer로 지정하였고, 변수명 heightB는 타입 파라미터를 Double로 지정하였다. 각 각의 타입 파라미터는 Height 객체의 임의의 타입파라미터 T와 매핑되어, 정수형, 실수형 객체 인스턴스가 생성된다.

제네릭을 통해 하나의 클래스로 동적인 타입을 가지는 객체를 생성하는 것은 장점이 많다.

예를 들어, 제네릭 타입이 아닌 모든 객체의 최상위 객체인 java.lang.Object 을 통해 정수형과 실수형 데이터를 받는다고 가정해보자.

@Getter
public class HeightV2 {
    private Object o;
}

public class GenericMain {

    public static void main(String[] args) {

        HeightV2 heightC = new HeightV2();
        // 정수형, 자동타입변환
        heightC.setValue(178);
    // 강제타입변환
        Integer a = (Integer) heightC.getValue();


        HeightV2 heightD = new HeightV2();
        // 실수형, 자동타입변환
        heightD.setValue(180.4);
    // 강제타입변환
        double b = (double) heightD.getValue();

    }

}

setter 메소드를 통해 정수형, 실수형 데이터를 넣을 땐, Object 타입으로 자동타입변환이 이루어지며, getter 메소드를 통해 데이터를 가져올 때는 강제타입변환이 필요하다. 이 과정은 시스템 자원을 낭비하는 코딩이 될 수 있다.(물론 미미하겠지만..)

위와 같은 상황에서 제네릭 타입을 사용하면,

Height<Integer> heightA = new Height<>();
heightA.setT(178);
Integer t = heightA.getT();

Height<Double> heightB = new Height<>();
heightB.setT(180.4);
Double d = heightB.getT();

저장할 때와 불러올 때 모두 자동타입변환 및 강제타입변환이 발생하지 않는다.

제네릭 메소드

제네릭 메소드는 리턴타입 앞에 <> 기호를 추가하고, 타입파리머터 및 리턴 타입, 매개 타입을 타입 파라미터의 타입으로 기술하여 사용한다.

public static <T> Height<T> makeHeight(T t) {
    Height<T> height = new Height<>();
    height.setT(t);
    return height;
}

public static void main(String[] args) {
    Height<Integer> heightE = makeHeight(178);
    Height<Double> heightF = makeHeight(180.4);
}

매개값을 보고 구체적인 타입을 추정하여 제네릭 메소드를 호출할 수 있다.

제한된 타입 파라미터

제네릭 타입에 타입 파라미터를 제한할 수 있다. 타입 파라미터를 제한하기 위해서는 타입 파라미터 뒤에 extends 키워드를 통해 상위 타입을 명시한다.

public class A extends B{
    ...
}

public class B {
    ...
}

public class C {
    ...
}

B 클래스를 상속한 A 클래스, B 클래스, C 클래스

public static <T extends B> void makeAlphabet(T t) {
    if (t instanceof A) {
        System.out.println("Type A");
    } else if (t instanceof B) {
        System.out.println("Type B");
    } else if (t instanceof C) {
        System.out.println("Type C");
    } else {
        System.out.println("no matching");
    }
}

makeAlphabet(new A()); // 허용
makeAlphabet(new B()); // 허용
makeAlphabet(new C()); // 허용되지 않음

instanceof 연산자를 사용하여 매개타입을 알아보는 메소드가 있다. 이를 통하여 타입 파라미터의 제한을 확인해 보자.

<T extends B> 타입 파라미터를 통하여, 타입 파라미터는 B 타입을 최상위 타입으로 제한할 것이라는 것을 명시해주었다. 따라서 B 클래스를 상속한 A 클래스, B 클래스는 해당 메소드를 호출할 수 있지만, C 클래스의 경우, 제한된 타입 파라미터로 인식되어 컴파일 에러가 발생한다.

[HTTP] HTTP 응답 상태코드 정리하기();

devyu — Mon, 19 Apr 2021 00:02:23 +0900

HTTP 응답의 상태코드 정리를 간단하게 해보자

크롬 개발자도구 Network 탭을 통해 요청과 응답을 확인할 수 있다.

모든 HTTP 요청에는 HTTP 응답이 있다. 그 응답 속에는 항상 상태코드(Status Code)가 있는데, 이를 통해 요청을 준 클라이언트에게 서버단의 처리 결과를 알려줄 수 있다.

개발자로서 항상 200번 대의 응답을 만나는 것은 아니니 400, 500 번대 응답도 알아두는게 도움이 될 것 같다.

HTTP 상태코드 100 ~ 1xx

100번 대의 상태코드는 정보성 상태를 의미하며 HTTP/1.1에서 첫 도입되었다.

구간	상태코드	사유구절	설명
100 ~ 1xx	100	Continue	클라이언트의 요청의 일부가 받아들여졌으며, 클라이언트는 계속해서 요청의 나머지를 계속 이어서 보내야함을 의미하는 상태
100 ~ 1xx	101	Switching Protocols	서버가 프로토콜을 바꾸었음을 나타내는 상태

100번 상태코드는 클라이언트가 본문을 서버에게 보낼 때, 그 이전에 서버에서 본문을 받아들일 것이지 확인하고자 할 때 사용되며 100 Continue로 응답한다. 클라이언트는 측에서 해당 응답을 받으려면 Expect 요청 헤더에 100-continue 값을 포함하여 보내야만 한다.

서버는 100-continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 Continue 혹은 400번 대의 에러코드로 응답해야만 한다.

HTTP 상태코드 200 ~ 2xx

200번 대의 상태코드는 '성공' 을 의미하며, HTTP 통신에서 가장 흔하게 볼 수 있다.

구간	상태코드	사유구절	설명
200 ~ 299	200	OK	요청을 정상적으로 처리하였고 본문에 요청된 리소스를 포함하고 있는 상태
	201	Created	서버에 개체를 생성하라는 요청을 위한 성공 상태
	202	Accepted	서버는 클라이언트의 요청에 대하여 수용하였으나, 아직 그 어떤 동작도 수행하지 않은 상태
	203	Non-Autohritative Information	헤더에 들어있는 정보가 리소스 사본에서 왔으며, 리소스에 대한 메타 정보를 검증하지 못한 경우 응답하는 상태
	204	No Content	요청을 정상적으로 처리하였고 본문을 포함하지 않는 상태
	205	Reset Content	브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라는 것을 알려주기 위한 상태
	206	Paritail Content	클라이언트의 요청에 대하여 부분 혹은 범위적인 성공을 나타내는 상태

HTTP 상태코드 300 ~ 3xx

300번 대의 상태코드는 '리다이렉션' 에 대한 코드이며, 클라이언트의 요청에 대하여 원하는 리소스가 다른 위치에 있다는 것을 전달하거나 해당 리소스의 대안 응답을 제공한다.

리다이렉션 상태코드와 Location 헤더를 사용하여 브라우저에게 새 위치로 재 요청을 보내도록 할 수 있다.

구간	상태코드	사유구절	설명
300 - 3xx	300	Multiple Cohoices	클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환하는 상태
	301	Moved Permanently	요청한 URL이 옮겨졌을 때 사용되는 상태. Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 함.
	302	Found	요청한 URL이 옮겨졌을 때 사용되는 상태. Location 헤더의 URL은 임시로 이동되는 목적으로 사용되며 이후의 요청에서는 원래의 URL을 사용해야 함.
	303	See Other	클라이언트에게 리소스를 다른 URL에서 가져올 것을 말하고자 할 때 사용되는 상태. Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 함. 303 상태코드의 주 목적은 POST 요청에 대한 응답이며 GET 요청으로 리다이렉트 시킨다.
	304	Not Modified	클라이언트는 If-Modified-Since 헤더를 사용하여 조건부 요청을 할 수 있다. 조건부 헤더의 정보를 바탕으로 서버의 리소스가 수정된 사항이 없을 경우 반환하는 상태. 304 상태는 리소스 수정이 없기때문에 응답 본문이 존재하지 않는다.
	305	Use Proxy	리소스가 반드시 프록시를 통해서 접근되어야 함을 나타내기 위해 사용되는 상태.
	307	Temporary Redirect	요청한 URL이 옮겨졌을 때 사용되는 상태. Location 헤더의 URL은 임시로 이동되는 목적으로 사용되며 이후의 요청에서는 원래의 URL을 사용해야 함.

HTTP 상태코드 400 ~ 4xx

400번 대의 상태코드는 '클라이언트 요청에 대한 에러' 를 설명하는 코드이다. 클라이언트의 요청을 서버가 처리할 수 없을 경우 발생하며 대게 브라우저를 통해 처리된다.

구간	상태코드	사유구절	설명
400 ~ 4xx	400	Bad Request	클라이언트의 요청이 잘못된 것을 알려주는 상태
	401	Unauthorized	인증이 되지 않은 클라이언트에게 인증을 요구하기 위한 상태
	402	Payment Required	현재 사용되지 않는 상태
	403	Forbidden	서버에서 클라이언트의 요청을 거부하고자 할 때 사용되는 상태. 인증은 되었으나 허가되지 게시물에 접근하고자 할 때 발생 할 수 있음.
	404	Not Found	존재하지 않는 URL에 접근할 때 응답하는 상태
	405	Method Not Allowed	요청한 URL에 대하여 지원하지 않는 메서드의 요청을 받았을 때 사용하는 상태. Allow 헤더를 포함하여 클라이언트가 인지할 수 있도록 한다.
	406	Not Acceptable	클라이언트가 요청한 URL에 대한 리소스 중 클라이언트가 받아들일 수 있는 것이 없는 경우 사용되는 상태
	407	Proxy Authentication Required	접근하는 리소스에 대한 인증을 요구하는 프락시 서버를 위해 사용되는 상태
	408	Request Timeout	클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 408 상태를 응답하면서 연결을 끊을 수 있음.
	409	Conflict	클라이언트의 요청이 리소스의 충돌을 일으킬 염려가 있을 때 사용되는 상태
	410	Gone	404 상태와 비슷하나 한 때, 서버가 해당 리소스를 갖고 있었을 경우 응답하는 상태
	411	Length Required	서버가 클라이언트의 요청에 Content-Length 헤더가 있을 것을 요구할 때 사용하는 상태
	412	Precondition Failed	클라이언트가 조건부 요청을 하였을 경우, 그 중 하나가 실패했을 때 사용하는 상태
	413	Request Entity Too Large	서버가 처리할 수 있는 한계를 넘은 크기의 요청을 클라이언트가 보냈을 경우 사용하는 상태
	414	Request URI Too Long	서버가 처리할 수 있는 한계를 넘은 길이의 요청 URL이 포함된 요청을 클라이언트가 보냈을 경우 사용하는 상태
	415	Unsupported Media Type	서버가 이해하지 못한 내용 유형의 헤더 및 본분을 클라이언트가 요청하였을 경우 응답하는 상태
	416	Requested Range Not Satisfiable	리소스의 특정 범위를 요청하였으나, 그 범위가 잘못되었을 경우 사용되는 상태
	417	Expectation Failed	요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용되는 상태

HTTP 상태코드 500 ~ 5xx

500번 대의 상태코드는 '서버 자체 에러' 를 의미한다. 클라이언트 측에서 올바른 요청을 보냈음에도 서버가 처리를 할 수 없는 상태

구간	상태코드	사유구절	설명
500 ~ 5xx	500	Internal Server Error	서버가 요청을 처리할 수 없게 만드는 에러가 발생한 경우 응답하는 상태
	501	Not Implemented	클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용하는 상태(서버가 지원하지 않는 메서드로 요청)
	502	Bad Gateway	프록시나 게이트웨이로부터 잘못된 응답을 받았을 경우 사용되는 상태
	503	Service Unavailable	현재 서버에서 요청을 처리해줄 수 없는 상태
	504	Gateway Timeout	프록시나 게이트웨이로부터 응답을 기다리다 발생한 타임아웃에 대한 상태
	505	HTTP Version Not Supported	서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용하는 상태

[git] 커맨드라인을 통한 깃(git) 명령어 정리

devyu — Fri, 10 Apr 2020 02:34:49 +0900

해당 포스팅은 생활코딩의 egoing님 Git 강의를 듣고 정리한 자료이다.

Git의 핵심 목적

버전관리
백업
협업

1. 버전관리

파일이 변경되었을때 변경사항들을 버전으로 만들어서 관리하는것.

버전관리 사이클

init

현재 디렉토리를 git을 통해 버전관리를 요청한다.
버전이 저장되는 저장소(repository)를 생성하는 명령어

git init

status

git을 통해 관리하고 있는 디렉토리의 상태를 묻는 명령어

git status

add

working-directory의 수정사항을 버전으로 만들기 위해 staging-area로 올리는 명령어

// [파일이름]을 staging-area 올린다.
git add [파일이름]

// 모든 수정된 file을 staging-area에 올린다.
git add .

commit

staging-area에 올라와 있는 수정사항을 저장소(repository)로 보내서 버전으로 만드는 명령어

git commit

// -m : 커맨드라인에서 직접 commit 메시지 적기
git commit -m "commit message"

// -am : add & commit 메시지 적기
// -am 설정은 Untracked 파일에는 사용할 수 없기 때문에 최초 1번의 add 명령어로 
// staging-area에 올려서 tracked 상태가 되어야 한다.
// 추적되지 않은 파일이 추적되는 것을 막을수 있다.
git commit -am "commit message"

// --ammend : 마지막 commit 메시지 수정하기
git commit --ammend

log

commit 내역을 확인하기 위한 명령어

git log

// -p : commit 상세 내용 보기
git log -p

// --oneline : commit 내역 한줄로 보기
git log --oneline

// --all : 모든 branch의 로그 보기
git log --all

// --graph : 그래프 형식으로 로그 보기
git log --graph

diff

difference의 약자로 수정된 working-directory의 수정된 차이점을 보여주는 명령어
마지막 commit 버전과 working-directory의 차이점을 통해서 commit하기 전에 최종적으로 검토할 수 있다.

git diff

checkout

commit 버전을 만든 시점으로 돌아가는 명령어

// commit ID값 입력
git checkout b322b7a993d1a98ac132319667509097e7674cd6

// 해당하는 branch로 이동
git checkout [branch 이름]

자동으로 생성되는 commit ID값

reset

commit ID값을 통해 해당하는 버전으로 리셋하는 명령어(선택한 버전이 되겠다.)
선택된 버전 이후의 commit 버전은 모두 사라진다.

git reset --hard 3a1489b8f528bd3b4dd7593a61156b005a5aab5e

staging-area에 올라오기 전 working-directory에 존재하는 변경사항을 마지막 버전으로 되돌리는 명령어

git reset --hard

revert

선택한 commit 버전의 전 버전으로 되돌리는 명렁어(선택한 버전의 이전 버전으로 되돌리겠다.)
reset의 경우 선택한 버전이 되서 그 이후의 커밋 버전을 지우지만 revert는 선택한 버전의 이전 버전을 복사해서 새로운 커밋 버전으로 생성하는 개념이다.

git revert 28a3d81b47044ca203affd2082c929b235f44cb2

3개의 커밋 내역

git log를 통해 확인한 commit 내역이다. 위 내역에서 커밋 메시지 "R3"를 revert 한다면 해당 커밋의 이전의 커밋으로, 즉 커밋 메시지 "Message 3"의 상태로 되돌아 간다. revert는 코드의 상태가 되돌아가지만 커밋 메시지 "R3"에 대한 내역은 사라지지 않고 새롭게 커밋을 생성하는 개념이다.

만약 커밋 메시지 "Message 2" 로 가기 위해서는 바로 revert Message 3를 해야할 것 같지만, 역순으로 작업을 해야한다. 즉, revert R3 를 하고 revert Message 3를 해야 Message 2로 돌아갈 수 있는 것이다.

2. Branch & Conflict

branch

브랜치 목록을 확인하는 명령어
기본은 master 브랜치 위에서 작업을 하게된다.

// branch 목록 보기
git branch

// branch 생성
git branch [생성할 branch 이름]

checkout

해당 브랜치로 이동하는 명령어

// HEAD 브랜치 이동
git checkout [branch 이름]

// commit 값으로 이동(detacted)
git checkout [commit ID값]

저장소를 생성하면 기본적으로 HEAD가 만들어지고 기본적으로 master branch를 가리킨다. checkout은 HEAD의 값을 바꾸는 기능이다. 만약 checkout 명령어를 통해 브랜치가 아닌 commit ID값을 입력하면 브랜치로부터 떨어져있다는 detacted되 있다고 한다.

merge

브랜치를 병합하기 위한 명령어
병합을 하기 위해서 우선 master branch 상태가 되어야 한다.

// 병합하기전 master branch 이여야 한다.
git checkout master

git merge [병합할 branch 이름]

충돌(conflict)

같은 라인에서 각각의 수정이 있는 파일을 병합(merge)하였을 경우 발생하는 충돌.

충돌 발생 로그

merge 이후 충동이 일어난 파일의 내부

'<<<<<' 에서 '=====' 사이의 내용은 HEAD, 즉 현재 브랜치의 내용을 나타내고,

'=====' 에서 '>>>>>' 사이의 내용은 w3 브랜치의 내용을 나타낸다.

git은 같은 라인에서 브런치 각각의 수정을 자동으로 병합할 수 없으므로 사용자에게 보기를 주고 선택하도록 하는 것이다.

3. backup

remote

지역저장소(Local Repository)의 파일을 원격저장소(Remote Repository)와 연결하는 명령어

// origin은 원격저장소 별칭으로 origin을 기본으로 한다.
git remote origin [원격저장소에 생성한 주소 URL]

// 연결된 원격 저장소 확인
git remote -v

clone

원격저장소(Remote Repository)의 파일을 복제해서 지역지역소(Local Repository)를 만드는 명령어
원격저장소의 이름을 딴 폴더가 생성되고 폴더 안에서 프로젝트가 git을 통해 관리된다.

git clone [원격저장소에 생성한 주소 URL]

push

지역저장소(Local Repository)에 존재하는 commit된 파일들을 원격저장소(Remote Repository)에 밀어넣는 명령어

git push

pull

원격저장소(Remote Repository)의 파일을 지역저장소(Local Repository)에 당겨오는 명령어

git pull

4. collaboration

fetch

원격저장소만 업데이트하는 명령어
merge 명령어를 통해 업데이트 된 파일과 병합해야 한다. 신중하게 파일을 pull하고 싶을때 사용된다.
즉, pull = fetch + merge

git fetch

// 가장 최신의 커밋을 병합해주는 명령어
git merge FETCH_HEAD

cherry-pick

해당하는 commit 버전이 생성된 당시의 변화만을 가져와서 병합하는 명령어
버전이 생성되었을때의 변화를 합쳐서 새로운 버전을 만들어내는 것

git cherry-pick [commit ID값]

[JPA] 페치조인(fetch join)이란?

devyu — Fri, 3 Apr 2020 04:09:25 +0900

페치조인(fetch join)

기존 SQL의 조인이 아님
JPQL의 성능 튜닝을 위해 제공되는 조인
연관된 엔티티 or 컬렉션을 SQL 한번에 함께 조회하는 기능

간단한 예제를 보자.

@Entity
@Getter
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String username;
    private int age;
    
    // 양방향 연관 필드
    // 연관관계 주인
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

@Entity
@Getter
public class Team {

    @Id @GeneratedValue
    private Long id;

    private String name;

    // 양방향 연관 필드
    @OneToMany(mappedBy = "team")
    private List<Member> memList = new ArrayList<Member>();

}

위 두개의 엔티티는 회원과 팀을 나타내고 있으면서 N : 1 양방향 매핑으로 동작하고 있다. 연관관계의 주인은 N쪽인 회원 엔티티로 선정하였고 FetchType.Lazy를 통해 조회과정에서 지연로딩 전략을 선택하였다.

페치조인을 적용해보자.

// JPQL
select m from Memeber m join fetch m.team

// 실제 데이터베이스에 전송되는 SQL
SELECT M.*, T.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID = T.ID

JPQL에서 join fetch 를 사용하면 실제 SQL에서는 두 테이블을 조인한 테이블을 조회할 수 있다. 데이터베이스로 전송되는 실제 SQL을 자세히 보면 FetchType.EAGER를 사용한 즉시로딩 전략으로 조회한 것 SQL이 같다는 것을 알 수 있다.

(엔티티에서 지연로딩 전략으로 세팅을 해도 JPQL에서 페치조인으로 날리는 것이 우선순위)

즉시로딩 전략은 묵시적인 방식이라서 원하지 않는 타이밍에도 항상 연관필드를 조인을 하고 결과를 반환한다. 물론 조인을 하고나서 데이터를 처리하는 것이 훨씬 효율적인 구성이 있을텐데 그때 바로 JPQL 페치조인을 사용하는 것이다. JPQL 페치조인은 명시적으로 동적인 타이밍에 원하는 객체그래프를 탐색할 수 있어 유용하다.

[JPA] 경로표현식(묵시적 내부조인과 명시적 내부조인)

devyu — Fri, 3 Apr 2020 02:38:36 +0900

경로표현식

' . ' 을 찍어서 객체 그래프를 탐색 하는것

상태필드

단순히 값을 저장하기 위한 필드(ex. username)
경로 탐색의 끝. 더 이상의 탐색할 것이 없음

String query = "select m.username from Member12 m";
List<String> resultList = em.createQuery(query, String.class).getResultList();

JPQL을 통해 데이터베이스로 날라간 실제 SQL을 보면 상태필드 조회는 기존의 JPQL과 같음을 확인할 수 있다.

연관필드

단일값 연관필드 : @ManyToOne, @OneToOne 대상이 엔티티일 경우
- 묵시적 내부조인 발생
- 추가 탐색 가능(ex. m.team.name)
컬렉션 값 연관필드 : @OneToMany, @ManyToMany 대상이 컬렉션일 경우
- 묵시적 내부조인 발생
- 추가 탐색 불가능(컬렉션 리스트 중에서 특정 하나만 가져오지 못한다는 것을 생각하자. 기껏해야 size 정도만 가져올 수 있다.)
- 단, 명시적인 조인을 사용하면 컬렉션 값 연관필드 추가 탐색이 가능하다.
  - select m from Team t join t.members m
  - FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통해 탐색 가능

String query = "select m.team from Member12 m";
List<Team12> resultList = em.createQuery(query, Team12.class).getResultList();

JPQL을 통해 연관필드를 조회하면 실제 SQL에서는 내부적으로 연관 테이블을 조인한다. 묵시적 내부조인이 발생한 것을 확인할 수 있다. (묵시적 내부조인은 쿼리를 성능 튜닝하기 굉장히 까다롭기 때문에 실무에서는 사용을 자제해야 한다고 한다.)

실무에서는 묵시적 내부조인을 쓰지말고 명시적 내부조인을 사용하는 것이 바람직하다.

[JPA] JPA 쿼리 지원 방식(JPQL)

devyu — Mon, 30 Mar 2020 02:43:14 +0900

JPA 쿼리 지원 방식

JPA는 데이터베이스에 데이터를 주고받기 위한 다양한 쿼리 방식을 지원한다.

JPQL
- 가장 단순한 조회 방법
  - EntityManager.find()
  - 객체 그래프 탐색(a.getB().getC())
- 테이블이 아닌 매핑된 엔티티를 대상으로 검색(SQL은 테이블을 대상으로 검색)
- JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공
- ANSI 표준 SQL을 지원하는 문법 모두 적용이 가능
- SQL을 추상화해서 특정 데이터베이스에 의존하지 않는다.
- 단순 String 값으로 쿼리가 쓰이기 때문에 동적 쿼리를 만들기 어렵다.
Criteria
- 쿼리를 String 문자가 아닌 자바 코드로 작성하기 때문에 컴파일 오류를 찾기 쉬움
- 동적 쿼리를 짜기 수월하지만 코드의 가독성이 매우 떨어져 유지보수가 어려움
- 사용 빈도가 굉장히 낮음
QueryDSL
- 오픈소스
- 쿼리를 String 문자가 아닌 자바 코드로 작성하기 때문에 컴파일 오류를 찾기 쉬움
- 동적쿼리 작성이 수월하고 코드가 직관적이고 쉽다.
- 실무에서 많이 사용되는 방식
네이티브 SQL
- JPA가 직접 SQL을 사용하는 기능
- JPQL로 해결할 수 없는 특정 데이터베이스에 의존적인 기능을 사용할 때 쓰임

JPQL(Java Persistence Query Language)

JPQL은 객체지향 쿼리 언어이므로 테이블을 대상으로 쿼리 하는 것이 아닌 엔티티 객체를 대상으로 쿼리 한다, 또한 SQL을 추상화해서 특정 데이터베이스에 종속되지 않고 사용할 수 있다.

select m from Member as m where m.name = "devyu"

Member는 테이블이 아닌 엔티티 객체이며 대소문자를 구분함을 유의하자.

별칭은 꼭 사용되어야 하고 as는 생략이 가능하다. ANSI SQL에 따른 표준 함수들도 사용할 수 있다.(ex, SUM, AVG, MAX, MIN, COUNT 등)

TypeQuery와 Query

TypeQuery는 반환 타입이 명확할 때 사용되고 Query는 반환타입이 명확하지 않을 때 사용된다.

// TypedQuery 타입 정보를 받을 수 있을 때(Member.class 명시)
TypedQuery<Member> createQuery = em.createQuery("select m from Member m", Member.class);
// TypedQuery 타입 정보를 받을 수 있을 때(Integer.class 명시)
TypedQuery<Integer> createQuery2 = em.createQuery("select m.age from Member m", Integer.class);

// Query 타입 정보를 받을 수 없을 때(반환값이 int와 String)
Query createQuery = em.createQuery("select m.age, m.username from Member m");

조회 API

query.getResultList();
- 결과가 하나 이상일 때, 리스트 반환
- 결과가 없다면 빈 리스트
query.getSingleResult();
- 결과가 단 하나뿐일 때, 단일 객체 반환
- 결과가 없다면 javax.persistence.NoResultException 발생
- 결과가 둘 이상이라면 javax.persistence.NonUniqueResultException 발생

파라미터 바인딩

이름 기준 바인딩

em.createQuery("select m from Member11 m where m.username=:username")
              .setParameter("username", "devyu")
              .getSingleResult();

바인딩하려는 위치에 ' : ' 를 사용하고 바인딩 이름을 적는다. setParameter() 메서드에 바인딩 이름과 실제 적용될 값을 파라미터로 넘겨준다.

위치 기준 바인딩

em.createQuery("select m from Member11 m where m.username=?1")
              .setParameter(1, "devyu")
              .getSingleResult();

바인딩하려는 위치에 ' ? ' 를 사용하고 바인딩 순서를 적는다. setParameter() 메서드에 바인딩 순서와 실제 적용될 값을 파라미터로 넘겨준다. 위치에 민감하기 때문에 사용을 실수가 나올 수 있는 바인딩 방법이다.

프로젝션

프로젝션이란 SELECT절에 조회할 대상을 지정하는 것이며 프로젝션의 대상은 엔티티, 임베디드 타입, 스칼라 타입(숫자, 문자 등 기본 데이터를 의미)이 있다.

@Entity
public class Member{

	@Id @GeneratedValue
	@Column(name =  "MEMBER_ID")
	private Long id;
	private String username;
	private int age;
    
	@Embedded
	private Address address;

	@ManyToOne
	@JoinColumn(name = "TEAM_ID")
	private Team team;
}

// 엔티티 프로젝션
select m from Member m

// 엔티티 프로젝션
select m.team from Member m

// 임베디드 타입 프로젝션
select m.address from Member m

// 스칼라 타입 프로젝션
select m.username, m.age from Member m

SELECT를 통해 조회된 엔티티는 영속성 컨텍스트 속에서 관리된다. 엔티티 타입으로 데이터를 받고 조작할 수 있다.

그런데 숫자, 문자 등 여러 타입이 겹친 스칼라 타입 프로젝션의 경우 어떤 타입으로 데이터를 전달받을까?

Object[] 타입으로 받기

// 단순 값 받기 Object[]
List<Object[]> resultList = em.createQuery("select m.age, m.username from Member m")
		.getResultList();
// age
System.out.println(resultList.get(0)[0]);
// username
System.out.println(resultList.get(0)[1]);

new 명령어를 통한 DTO로 받기

public class MemberDTO {

	private int age;
	private String username;
	
    // 생성자 순서 중요
	public MemberDTO(int age, String username) {
		this.age = age;
		this.username = username;
	}
	
    // getter, setter...
}

List<MemberDTO> resultList = 
	em.createQuery("select new 패키지경로.MemberDTO(m.age, m.username) from Member m", MemberDTO.class)
	.getResultList();

// age
System.out.println(resultList2.get(0).getAge());
// username
System.out.println(resultList2.get(0).getUsername());

패키지 명을 포함한 전체 클래스명을 new 명령어를 통해 DTO 생성하여 값을 넣는 방법. 순서와 타입이 일치하는 생성자가 필수적으로 존재해야 한다.

페이징

JPA에서 페이징 API는 굉장히 간단하게 구현할 수 있다.

List<Member> resultList = 
	em.createQuery("select m from Member m order by m.age desc", Member.class)
	.setFirstResult(1)
	.setMaxResults(10)
	.getResultList();

setFirstResult() 메서드에 파라미터로 조회 시작 위치를 넣어주고 setMaxResults() 메서드의 파라미터로 조회할 데이터의 수를 넣어주기만 하면 된다.

사용하는 데이터베이스 방언 종류에 따라 페이징 관련 쿼리가 다르게 전달된다. 예를 들어 MySQL의 경우 limit와 offset을 이용한 쿼리가 나가고 Oracle의 경우 ROWNUM을 이용한 3중 뎁스로 쿼리가 나간다.

JPA 방언으로 지정된 데이터베이스의 종류에 따라 (MySQL(좌), Oracle(우)) 같은 코드임에도 다르게 나간다.

조인

내부조인(대괄호 생략가능)

select m from Member m [inner] join m.team t

외부조인(대괄호 생략가능)

select m from Member m left [outer] join m.team t

ON절 활용 조인

조인 대상 필터링
연관관계가 없는 엔티티 외부 조인 가능

// 회원과 팀을 조인하면서 팀이름이 'IT사업부'인 팀만 조인

// JPQL(연관관계 O)
select m, t from Member m left join m.team t on t.name = 'IT사업부'

// SQL
select m.*, t.* from Member m left join Team on m.team_id = t.id and t.name = 'IT사업부'

// 회원의 이름과 팀의 이름이 같은 대상 외부 조인

// JPQL(연관관계 X)
select m, t from Member m left join Team t on t.name = 'IT사업부'

서브쿼리

// 나이가 평균보다 많은 회원 조회
select m from Member m where m.age = (select avg(m2.age) from Member m2)

// 한 건이라도 주문한 회원 조회
select m from Member m where (select count(o) from Order o where m = o.member) > 0

JPA 표준 스펙은 WHERE절과 HAVING절에만 서브쿼리 사용가능하지만 Hibernate는 SELECT절까지 서브쿼리를 사용할 수 있다.

FROM절의 서브쿼리는 JPQL에서 불가능함.

JPQL 타입 표현

문자

'Hello'
- single quartation 안쪽에 문자열을 표현
'She''s'
- single quartation 안쪽 문자열에 single quartation이 사용된다면 한개 더 사용해서 이스케이프 문자를 만든다.

숫자

10L
- long형
10D
- double형
10F
- float형

ENUM

xyz.devyu.MemberType.Admin
- 자바 패키지명을 포함해서 넣어야 한다