전체 글

전체 글

    서비스는 꼭 인터페이스를 구현해야할까?

    https://seovalue.github.io/2022/01/07/why-service-needs-interface/

    블로그 이전하기

    티스토리를 잘 쓰고 있었는데, 마음 한 켠에는 Github 블로그를 쓰고 싶다는 생각이 있었다. 그래서 이번 기회에 옮겨보려고 한다! 글은 하나씩 대체할 생각이다 :) https://seovalue.github.io

    [Effective Java] 아이템 9. try-finally보다는 try-with-resources를 사용하라.

    아이템 9. try-finally보다는 try-with-resources를 사용하라. 자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야하는 자원이 많다. 예를 들자면, InputStream, OutputStream, Connection 등이 있다. 이러한 "자원 닫아주기" 행위는 놓치기 쉽기 때문에 예측할 수 없는 성능 문제로 이어지기도 한다. OutOfMemory와 같은.. 전통적으로는 자원 닫힘을 보장하는 수단으로서 try-finally 구문이 사용되었다. BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } 하지만 자원을 여러개 사용하게..

    [Effective Java] 아이템 8. finalizer와 cleaner 사용을 피하라.

    아이템 8. finalizer와 cleaner 사용을 피하라. 사실 2장에서 이 부분이 이해하기에 가장 까다로웠다. 자바에서는 두 가지 객체 소멸자를 제공한다. 그것이 바로 finalizer와 cleaner이다. 이 두 가지 객체 소멸자를 사용하면 명시적으로 바로 메모리를 해제할 수 있을까? 그건 아니다. 언젠가 해제될 순 있지만 곧바로 해제하는 것은 불가능하다. finalizer는 예측할 수 없고 상황에 따라 위험할 수 있다. 예를 들어, 불완전한 객체가 생성되고 해당 객체의 하위 객체에서 finalizer를 구현하며, finalizer의 정적 필드에 자신의 참조를 할당하여 가비지 컬렉터가 수집하지 못하게 막을 수 있다. cleaner는 Java9부터 finalizer의 대체제로 제시된다. cleane..

    [Effective Java] 아이템 7. 다 쓴 객체 참조를 해제하라.

    아이템 7. 다 쓴 객체 참조를 해제하라 이 글에서 다루는 내용은, 말 그대로 다 쓴 객체 참조를 해제하라! 라는 것이다. 자바를 사용하다 보면 GC라는 것이 동작한다. 따라서 우리는 다른 C++과 같이 메모리 관리를 필요로하는 언어보다 좀 더 메모리를 신경쓰지 않고, 프로그래밍을 할 수 있다는 장점이 있다. 혹시라도 GC에 대해서 잘 모르는 독자가 있다면, 이 글을 참조하길 바란다. 하지만, 우리가 신경쓰며 객체 참조를 해제해주어야할 때가 있다. 일반적으로 자기 메모리를 직접 관리하는 클래스라면 메모리 누수에 주의하여야한다. 예를 들어, 다음 코드에서 메모리 누수가 일어나는 위치를 찾아보자. public class Stack { private Object[] elems; private int size;..

    JPA에서 save와 saveAll은 어떤 차이를 가질까?

    https://seovalue.github.io/2021/12/09/jpa-save-and-save-all/ JPA save와 saveAll의 차이 - Milestone | Joanne Blog Student라는 간단한 도메인을 만들어서, save와 saveAll의 차이를 비교해보자. seovalue.github.io 블로그 이전 중입니다 :)

    DispatcherServlet의 @ResponseBody 응답 과정을 파고들어보자.

    https://seovalue.github.io/2022/01/02/digging-into-spring-web-flow/ Spring Web 요청 응답 흐름 파고들기 - Milestone | Joanne Blog 💡 궁금증 @ResponseBody 가 달린 응답을 하게 되면, 언제 어디서 JSON으로 변환할까? seovalue.github.io 블로그 이전 중입니다 :)

    모두의 네트워크 8장. 네트워크 전체 흐름 살펴보기

    모두의 네트워크 정리 1장. 네트워크의 첫걸음 2장. 네트워크의 기본 규칙 3장. 물리 계층: 데이터를 전기 신호로 변환하기 4장. 데이터 링크 계층: 랜에서 데이터 전송하기 5장. 네트워크 계층: 목적지에 데이터 전달하기 6장. 전송 계층: 신뢰할 수 있는 데이터 전송하기 7장. 응용 계층: 애플리케이션에 데이터 전송하기 8장. 네트워크 전체 흐름 살펴보기 이번 장에서는 OSI 모델의 각 계층 간에 데이터가 전달되고 처리되는 전체 과정에 대해 알아보자. 물리 계층 - 데이터를 전기 신호로 변환하는 데 필요하다. 데이터 링크 계층 - 랜에서 데이터를 송수신하는 데 필요하다. 네트워크 계층 - 다른 네트워크에 있는 목적지에 데이터를 전달하는 데 필요하다. 전송 계층 - 목적지에 데이터를 정확하게 전달하는 ..

    모두의 네트워크 7장. 응용 계층: 애플리케이션에 데이터 전송하기

    응용 계층의 역할 일반적으로 서비스를 요청하는 측을 클라이언트, 서비스를 제공하는 측을 서버라고 한다. 서버 측에는 웹 서버 프로그램과 메일 서버 프로그램 등이 있다. 이러한 애플리케이션은 응용 계층에서 동작한다. 즉, 애플리케이션이 동작하는 계층이라 응용 계층이다. (여기서는 세션 계층, 표현 계층을 모두 포함해 응용 계층이라고 칭한다.) 응용 계층에서는 사용자측의 요청을 전달하기 위해 통신 대상이 이해할 수 있는 메시지로 변환하고 전송 계층으로 전달하는 역할을 한다. 이를 위해서는 응용 계층의 프로토콜을 사용해야한다. HTTP / 웹 사이트 접속 DNS / 이름 해석 FTP / 파일 전송 SMTP / 메일 송신 POP3 / 메일 수신 HTTP란? 클라이언트는 웹 사이트를 보기 위해 서버의 80번 포트..

    모두의 네트워크 6장. 전송 계층: 신뢰할 수 있는 데이터 전송하기

    전송 계층의 역할 물리 계층, 데이터 링크 계층, 네트워크 계층의 3계층이 있으면 목적지에 데이터를 보낼 순 있다. 하지만 데이터가 손상되거나 유실되더라도 이들 계층에서는 아무것도 해 주지 않는다. 목적지에 신뢰할 수 있는 데이터를 전달하기 위해 필요한 계층이 바로 전송 계층이다. 전송 계층에는 오류를 점검하는 기능이 있다. 오류 발생 시 데이터를 재전송하도록 요청한다. 즉, 네트워크 계층은 목적지까지 데이터를 전달하고, 전송 계층에서는 데이터가 제대로 도착했는지 확인한다. 또한 전송 계층에서는 전송된 데이터의 목적지가 어떤 애플리케이션인지 식별하는 기능도 있다. 즉, 웹 브라우저로 전송하는 것인지 메일 프로그램으로 전송하는 것인지를 구별한다. 연결형 통신과 비연결형 통신 전송 계층의 특징은 신뢰성/정확..