장장스

[JPA] No converter found capable of converting from type [org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap] to type [com.web.blog.dto.post.PostidandviewcntWrapperclass] 오류

장장스 — Sun, 9 Jul 2023 15:18:34 +0900

No converter found capable of converting from type [org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap] to type [com.web.blog.dto.post.PostidandviewcntWrapperclass
오류

안녕하세요? 장장스입니다.

오늘은 JPA 사용 도중 발생한 오류 처리 방법을 정리입니다.

JPQL 프로젝션에서 발생하는 문제

List<MemberDto> memberDtoList = em.createQuery("select MemberDto(m.username, m.age) from Member m", MemberDto.class)
                    .getResultList();

JPQL을 사용한 데이터 조회시 필요한 필드만 갖도록 VO를 만들어 사용하였습니다.

No converter found capable of converting from type [org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap] to type [com.web.blog.dto.post.PostidandviewcntWrapperclass

그런데, 위와 같은 오류가 발생하였습니다.

해결방법 (new jpql.domain.MemberDto)

List<MemberDto> memberDtoList = em.createQuery("select new jpql.domain.MemberDto(m.username, m.age) from Member m", MemberDto.class)
                    .getResultList();

JPQL 프로젝션시 객체 생성을 하도록 하면 됩니다. new 명령어를 사용하고 DTO의 패키지명까지 써주면 해결 됩니다.

(다른 방법이 있으면 추가 기록할 예정입니다~)

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 공통 매핑 정보 @MappedSuperclass

장장스 — Sun, 9 Jul 2023 10:59:38 +0900

[JPA] 공통 매핑 정보 @MappedSuperclass

안녕하세요? 장장스입니다.

오늘은 JPA에서 공통 매핑 정보를 편리하게 사용하는 @MappedSuperclass 에 대해 정리해보겠습니다.

실무에서 공통으로 사용되는 칼럼들

실무에서 테이블을 만들 때 보통 최초생성자와 생성시간, 최종수정자와 수정시간을 저장하는 칼럼들을 사용한다. 매번 반복되는 테이블 칼럼을 반복해서 사용하는 것은 개발자에게 꽤나 번거로운 일이 될 것이라 생각한다. JPA에는 이처럼 공통적으로 매핑되는 칼럼을 쉽게 사용할 수 있도록 @MappedSuperclass 어노테이션을 통해 기능을 제공합니다.

@MappedSuperclass

위에서 언급한 최초생성자와 생성시간, 최종수정자와 수정시간을 공통으로 작성할 수 있도록 BaseEntity라는 클래스를 만들어 사용할 수 있습니다.

@MappedSuperclass
@Getter @Setter
public abstract class BaseEntity {

    @Column(name = "INSERT_MEMBER")
    private String createBy;
    private LocalDateTime createDate;
    @Column(name = "UPDATE_MEMBER")
    private String lastModifiedBy;
    private LocalDateTime lastModifiedDate;

}

위처럼 공통정보를 담은 BaseEntity 클래스를 상속하여 사용 할 수 있습니다.

@Entity
public class Member extends BaseEntity{
    ...
}

공통 매핑 정보를 담는 BaseEntity는 직접 생성해서 사용하지 않으므로 추상(abstract) 클래스를 사용을 권장합니다.

@MappedSuperclass를 사용한 BaseEntity는 엔티티로 사용할 수 없습니다. BaseEntity를 상속받은 자식 클래스는 매핑 정보만 제공하고 조회할 수 있습니다. (em.find(BaseEntity)는 되지 않습니다.)

참고로 엔티티는 @Entity, @MappedSuperclass 가 선언된 클래스만 상속 받을 수 있습니다.

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 상속관계 맵핑 @Inheritance, @DiscriminatorColumn

장장스 — Sun, 25 Jun 2023 15:03:54 +0900

상속관계 맵핑 @Inheritance, @DiscriminatorColumn

안녕하세요? 장장스입니다.

JPA 상속관계 맵핑 @MappedSuperclass 에 대해 정리해보겠습니다.

상속관계 맵핑

일반적인 관계형 데이터베이스는 슈퍼타입 서브타입 관계라는 모델링 기법이 있습니다.

JPA에서는 슈퍼타입 서브타입 관계를 상속을 활용하여 구현할 수 있습니다.

@Inheritance

@Inheritance 어노테이션의 strategy 속성을 통해 전략을 선택 할 수 있습니다.

@DiscriminatorColumn 어노테이션은 부모 클래스에 선언합니다. 하위클래스를 구분하는 용도의 칼럼을 사용합니다. name 속성을 통해 이름을 설정할 수 있습니다. default 값은 DTYPE 입니다.

@Entity
@Getter @Setter
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn
public abstract class Item {

    @Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
}

하위 클래스는 상위 클래스를 상속 받습니다. 이때 @DiscriminatorValue 어노테이션으로 엔티티를 저장할 때 슈퍼타입의 구분 칼럼에 저장할 값을 지정합니다. 선언하지 않으면 클래스 이름이 기본값으로 들어가게 됩니다.

@Entity
@Getter @Setter
@DiscriminatorValue(value = "A")
public class Album extends Item{
    private String artist;
}

@Entity
@Getter @Setter
@DiscriminatorValue(value = "B")
public class Book extends Item{

    private String author;
    private String isbn;
}

@Entity
@Getter @Setter
@DiscriminatorValue(value = "M")
public class Movie extends Item{
    private String director;
    private String actor;
}

InheritanceType.JOINED 전략

일반적인 정규화 된 방법으로 구현하는 전략입니다. @DiscriminatorColumn을 선언해야만 DTYPE 칼럼이 생성됩니다. 조인을 통해 어떤 하위 클래스인지 확인을 할 수 있으나 명확한 구분을 위해 DTYPE을 선언하는게 좋습니다.

다만, 조회시 조인을 많이사용하게 되고 쿼리가 복잡해질 수 있어 성능저하가 올 수 있습니다. 추가로 테이블에 데이터 저장시 INSERT SQL 2번 호출하게 됩니다.

InheritanceType.SINGLE_TABLE 전략

하나의 테이블에 모두 저장하고 DTYPE으로 구분하는 전략입니다. 하나의 테이블에 모두 저장하기 때문에 DTYPE 없이는 구분을 할 수 없어 @DiscriminatorColumn 을 선언하지 않아도 DTYPE칼럼이 생성됩니다.

INSERT SQL 1번만 호출하게 됩니다. 자식 엔티티가 매핑한 컬럼은 모두 null 사용을 하게 됩니다, 하나의 테이블에 모든 데이터를 저장하므로 테이블이 커질 수 있습니다. 때문에 상황에 따라서 조회 성능이 오히려 느려질 수 있습니다.

InheritanceType.TABLE_PER_CLASS 전략 (비추천)

JOINED 전략과 유사하지만 슈퍼타입(여기서는 Item) 칼럼들을 서브타입으로 내리는 전략입니다. 각각의 구현 클래스마다 테이블 생성 전략을 적용 할 수 있으며, NOT NULL 제약조건을 사용할 수 있습니다.

그러나, 여러 자식 테이블을 함께 조회하기 위해서는 UNION SQL 을 사용해야만 합니다. 때문에 SQL 조회 성능이 떨어지게 고 여러 자식 테이블을 통합해서 SQL을 사용하기가 어렵습니다.

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 단방향 양방향 연관관계와 다중성 #다대일 #일대다 #일대일 #다대다

장장스 — Sun, 25 Jun 2023 01:16:25 +0900

[JPA] 단방향 양방향 연관관계와 다중성 #다대일 #일대다 #일대일 #다대다

안녕하세요? 장장스입니다.

JPA는 자바 진영의 표준 ORM(Object Relational Mapping)입니다. ORM에서 가장 중요한 것이 객체와 모델 사이의 관계를 정의하는 것입니다. 각 모델과의 연관 관계를 자바 코드로서 객체로 옮기는 것에 백퍼센트 정답은 없습니다. 구현하고자 하는 서비스의 도메인과 요구사항에 따라 적절하게 연관 관계를 정의해야 합니다.

단방향 관계, 양방향 관계

데이터베이스에서 테이블과 조인할때, 외래키(FK)로 하나로 양쪽 테이블을 조인이 가능합니다. 때문에 데이터베이스에서 테이블과 다른 테이블에는 방향이 없습니다.

반면에 JPA에서는 객체(엔티티)를 통해 또다른 객체(엔티티)를 참조합니다. Orders 객체가 Customer 객체를 참조하기 위해 Customer 클래스를 필드로 가집니다.

위의 그림처럼 객체사이에서 한 객체만이 다른 객체를 참조하고 있으면 단방향 관계라고 합니다.

객체 사이에서 양쪽 객체가 서로를 참조하고 있으면 양방향 관계라고 합니다. 양방향 관계를 정확히 말하면 객체가 서로를 단방향 관계로 참조하고 있는 것입니다.

Orders -> Customer : Orders.getCustomer()
Customer -> Orders : Customer.getOrders()

여기까지 내용을 정리하며 문득 드는 의문이 있었습니다.

데이터베이스처럼 양쪽 객체를 서로 참조하도록 하면 되지 않나?

실제로 양방향 관계로 객체끼리 서로 참조하게 해보면 문제가 매우 복잡해 지게 됩니다.

예를 들어, 일반적인 비즈니스에서 회원 엔티티는 많은 엔티티와 연관 관계를 형성할 수 밖에 없습니다. 이러한 경우에 모든 객체(엔티티)를 양방향 관계로 연결하게 되면 수많은 참조 필드가 생기게 된다는 것을 예상할 수 있습니다.

다른 문제로,객체가 서로를 참조하다보면 순환참조 문제가 발생할 수 있습니다. 때문에 toString(), lombok, JSON 생성 라이브러리를 사용할 때 주의를 기울여야 합니다. 컴파일 단계에서는 확인되지 않기 때문에 자칫하면 운영중에 큰 사고로 이어질 수 있습니다.

연관 관계의 주인

이제 우리는 객체의 두 관계중 하나에 연관 관계의주인을 정해야 한다는 사실을 알았습니다. 어떤 객체에 연관 관계의 주인을 설정해야 할까요?

대부분은 외래키가 있는 곳을 연관 관계의 주인으로 정합니다. (어떤 예외 상황이 있는지는 알지 못하여 나중에 그런 상황이 발생하면 추가로 정리하겠습니다.) 연관 관계의 주인인 객체만이 외래키를 등록하고 수정할 수 있습니다.

연관 관계의 주인이 아닌 쪽은 읽기만 가능하며, mappedby 속성으로 주인을 지정할 수 있습니다.

@Entity
public class Customer {
    @Id
    @GeneratedValue
    @Column(name = "customer_id")
    private Long id;

    private String name;

    @OneToMany(mappedBy = "customer")
    private List<Orders> ordersList = new ArrayList<>(); 
}

@Entity
public class Orders {

    @Id
    @GeneratedValue
    @Column(name = "order_id")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "customer_id")
    private Customer customer;

    private LocalDateTime order_date;
}

연관 관계 메서드

JPA는 객체 참조이기 때문에 연관 관계 주인과 주인이 아닌 객체에 모두 값을 입력해야 합니다.

Customer customer = new Customer();
customer.setName("장장스");
em.persist(customer); //INSERT

Orders order1 = new Orders();
order1.setCustomer(customer);
order1.setOrder_date(LocalDateTime.now());
em.persist(order1); //INSERT

위 코드를 실행시키고 나서 아래 코드를 출력하면 어떻게 될까요?

customer.getOrdersList().isEmpty();

ture 를 반환한다.

왜? ordersList가 비어있을까요? 데이터베이스와 달리 객체입니다. 연관관계의 주인인 customer객체에 ordersList에 별도로 order를 추가하도록 코드를 아래와 같이 수정해야 합니다.

Customer customer = new Customer();
customer.setName("장장스");
em.persist(customer); //INSERT

Orders order1 = new Orders();
order1.setCustomer(customer);
order1.setOrder_date(LocalDateTime.now());

customer.getOrdersList().add(order1); //연관 관계 주인에도 값을 추가한다.

em.persist(order1); //INSERT

위 코드처럼 order와 customer에 각각 값을 추가해야 하는데, 솔직히 불편하고 번거롭습니다. 이를 편리하게 하기 위한 방법으로 연관 관계 메서드를 정의하여 사용할 수 있습니다.

public void setCustomer(Customer customer) {
        this.customer = customer;
        customer.getOrdersList().add(this);
    }

양방향 연관 관계에서는 자바의 객체 상태를 고려해서 항상 양쪽에 값을 설정할 수 있도록 해야 합니다.

다중성

JPA는 테이블의 관계를 정할 때는 데이터베이스 테이블 관계를 기준으로 정합니다. JPA에서 제공하는 다중성 관계는 총 4가지 입니다.

◆ 다대일 ←→ 일대다

◆ 일대일 ←→ 일대일 (반대 동일)

◆ 다대 다 ←→ 다대다 (반대 동일)

다대일(N:1)

가장 많이 사용하는 다중성 관계이다. 데이터베이스는 다대일에서 무조건 다 쪽에 외래키(FK)가 있다.

다대일(N:1)의 단방향 관계

JPA로 넘어와서 먼저 다대일(N:1) 관계에서 다(N)인 객체에서 단순하게 일(1)인 객체로 단방향 참조를 살펴보겠습니다.

단방향 참조는, 테이블에 외래키가 있는 다(N)인 객체에서 일(1)인 객체로 연관관계 매핑 하면 됩니다.

다(N) : Member 일(1) : Team

1. @ManyToOne을 사용해서 다대일 관계를 매핑합니다..

2. @JoinColumn은 외래 키를 매핑할 때 사용한다. 매핑할 외래 키 이름은 name에 작성합니다.

@Entity
public class Member {
    //...
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    //...
}

다대일(N:1)의 양방향 관계

단방향 관계에서 추가적으로 양방향 관계로 매핑할 때, 일(1)인 객체에서 단방향 매핑을 해주게 됩니다.

일(1)인 객체에서 단방향 매핑을 하는 것은 데이터베스상의 테이블에 영향을 전혀 주지 않습니다. 이미 다대일(N:1) 관계로 다(N)인 객체에서 연관관계의 주인으로 외래키를 관리하고 있습니다.

다(N) : Member 일(1) : Team

1. @OneToMany 어노테이션을 사용한다.

2. 연관관계의 주인이 아니므로, 어디에 매핑이 되었는지에 명시해주어야만 합니다. 아래 코드의 mappedBy = "team" 은 Team 엔티티의 members 필드가 Member 엔티티의 team 필드에 의해 매핑 되었음을 의미합니다.

@Entity
public class Member {
    //...
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")   //외래 키가 있는 곳이 진짜 주인으로 정해라, Member.team
    private Team team;
    //...
}


@Entity
public class Team {
    //...
    @OneToMany(mappedBy = "team") //읽기용 외래키로 mappedBy
    private List<Member> members = new ArrayList<>();
    //...
}

일대다(1:N)

일대다(1:N)는 일(1) 연관관계의 주인을 갖는 관계입니다. 일(1) 객체에서 외래키를 관리하는 경우입니다. 보통 실무에서 사용을 권장하지는 않는다고 합니다. 예외적으로 일대다(1:N) 관계를 사용하는 경우가 있다고 하는데, 나중에 알게되면 추가적으로 포스팅하도록 하겠습니다.

일대다(1:N)의 단방향 관계

일(1)인 객체가 다(N)인 객체를를 가지는데, 다(N) 인 객체에서는 일(1)인 객체를 참조하지 않아도 된다라는 설계가 나올 수 있다. (객체지향적인 설계 관점에서 보면 충분이 나올 수 있는 경우라고 생각됩니다.)

그러나 데이터베이스 테이블 관점에서 보면, 무조건 다(N)쪽에 외래키가 들어가게 됩니다. 일(1)인 객체에서 다(N)인 객체가 변경되면, 데이터베이스에서 다(N) 테이블에 업데이트 쿼리가 실행되어 버립니다. 실무에서는 여러 테이블이 복잡하게 얽히기 때문에 이러한 상황이 발생하면 유지보수가 어렵게 됩니다.

테이블이 수십, 수백개 존재하는 실무에서는 매핑이나 설계는 명확해야 누구나 사용이 편리합니다. 가능하면 다대일 단방향 관계로 매핑하고, 필요할 경우 양방향 매핑을 통해서 해결하도록 합니다.

일(1) : Team 다(N) : Member

@OneToMany와 @JoinColumn을 이용해서 일대다(1:N) 단방향 매핑을 한다. @JoinColumn을 꼭 사용해야만 하며, 사용하지 않으면 조인 테이블 방식을 사용합니다.

@Entity
public class Team {
    //...
    @OneToMany
    @JoinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();
    //...
}

일대다(1:N)의 양방향 관계

일대다(1:N) 양방향 관계 는 공식적으로는 존재하지 않습니다.

@ManyToOne과 @JoinColumn을 사용해서 연관관계를 매핑하면, 다대일(N:1) 단방향 매핑이 되어버린다. 그런데 반대쪽 일(1)인 객체에서 이미 일대다(1:N) 단방향 매핑이 설정되어있다. 이런 상황에서는 두 엔티티에서 모두 테이블의 외래키를 관리 하게 되는 상황이 벌어진다.

이러한 상황을 막기 위해 insertable, updatable 속성값을 FALSE로 설정하고 읽기 전용 필드로 사용해서 양방향 매핑처럼 사용하는 방법이다. @JoinColumn(name = "team_id", insertable = false, updatable = false) .

insertable, updatable 속성값을 false로 만들어 읽기 전용으로 사용하도록 할 수 있다.

일대일(1:1)

일대일(1:1) 관계는 반대도 일대일(1:1)로 동일합니다.

일대일(1:1)의 단방향 관계

일대일 관계는 주 테이블, 대상 테이블 중에 외래키를 넣을 테이블을 선택 할 수 있습니다. 또한 외래 키에 유니크 제약조건이 추가되어야 일대일 관계가 됩니다.

일대일(1:1)의 양방향 관계

다대일(N:1)처럼 외래키가 있는 곳이 연관관계의 주인이다.

@OneToOne 어노테이션으로 일대일(1:1) 단방향 관계를 매핑합니다. @JoinColumn을 사용합니다.

@Entity
public class Member {
   //...       
   @OneToOne
   @JoinColumn(name = "locker_id")
   private Locker locker;
   //...
}

@Entity
public class Locker {
   //...       
   @OneToOne(mappedBy = "locker")
   private Member member;
   //...
}

다대다(N:M)

일반적인 관계형 데이터베이스에서는 정규화된 테이블 2개로 다대다(N:M)을 표현할 수 가 없어 중간에 연결 테이블을 추가해서 다대일, 일대다 관계로 풀어서 설계 합니다.

JPA에서 객체는 컬렉션을 사용하여 다대다 관계를 풀어낼 수 있습니다. 그러나 개발을 하다보면 서비스가 커지고 요건이 추가되며, 중간 연결 테이블에 칼럼이 추가되며 데이터가 들어가야 하는 일이 생기기도 합니다. 이렇게 처리 하게 되면, 중간에 숨겨진 테이블로 인해, 예상치 못한 쿼리가 나가게 됩니다. 따라서 다대다(N:M) 관계는 실무에서는 절대 지양해야 합니다. 다대일, 일대다 관계로 풀어서 사용하도록 합니다.

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 기본키(PK) 매핑 전략 IDENTITY, SEQUENCE, TABLE, AUTO

장장스 — Sat, 20 May 2023 16:28:04 +0900

[JPA] 기본키(PK) 매핑 전략

GenerationType.IDENTITY

GenerationType.SEQUENCE

GenerationType.TABLE

GenerationType.AUTO

안녕하세요? 장장스입니다.

오늘은 기본키(PK) 매핑 전략에 대해 정리해보겠습니다.

기본키 맵핑 어노테이션

@Id

기본키를 사용자가 직접 할당하여 사용한다.

@Id
private String id;

@GeneratedValue

기본키를 자동생성할때 사용한다.

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

기본키를 자동생성하는 @GeneratedValue 어노테이션은 4가지 전략이 있다.

@GeneratedValue (strategy = GenerationType.IDENTITY)

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private String id;

IDENTITY는 데이터베이스에 위임하는 전략이다. MySQL의 AUTO_INCREMENT와 같은 기능을 제공하는 MySQL, PostgreSQL, SQL Server, DB2에서 사용할 수 있다.

IDENTITY 전략은 DB에 적재 되기 전까지 PK 값을 알 수 없다. 예를 들어, AUTO_INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID값을 알 수 있다.

JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL을 실행한다. JPA에서는 PK값이 없는 데이터는 영속성 컨텍스트에 올릴 수가 없다. 때문에, persist 메서드가 실행될때 바로 insert가 실행되고 key 값을 가져온다. JDBC 내부적으로 insert 시에 key값을 가져오게 되어 있어 약간의 리소스를 더 사용하게 된다는 단점이 존재한다.

위와 같은 단점은, 개발할 때 크게 문제가 되지는 않는다.

@GeneratedValue (strategy = GenerationType. SEQUENCE)

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
private Long id;

SEQUENCE는 데이터베이스 시퀀스 오브젝트를 사용한다. 보통 ORACLE의 기본키 생성 전략으로 많이 사용한다.

시퀀스를 지정하지 않으면 기본 시퀀스 이름으로(ex.. hibernate_seq) 시퀀스 오브젝트를 생성하며, 직접 시퀀스 오브젝트를 설정하기 위해 @SequenceGenerator 어노테이션과 함께 사용한다.

@SequenceGenerator(
        name = "ZZS_SEQ_GENERATOR",
        sequenceName = "ZZS_SEQ", //매핑할 데이터베이스 시퀀스 이름
        initialValue = 1, allocationSize = 50)
public Class Zangzangs{

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "ZZS_SEQ_GENERATOR")
    private Long id;
    
    ...
    ...
    
}

SEQUENCE 전략을 생성할 때, int, long와 같은 원시타입(primitive type)은 0이 있어 사용을 추천하지 않는다.(기본키가 0부터 시작이 된다.)

보통 Integer, Long와 같은 래퍼 클래스를(wrapper class) 사용하며, Integer의 최대 크기가 21억밖에 안된다. ~~통장에 21억만 있으면 좋겠네..~~ (MAU가 높은 규모의 회사이거나, 장기간 서비스가 이루어지면 21억은 금방 찰수도 있다.)

요즘은 컴퓨터 성능이 좋아진 이유로 가능하면 무조건 Long 사용을 추천한다.

@SequenceGenerator

속성	설명	기본값
name	식별자 생성 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 때 처음 1 시작하는 수를 지정한다.	1
allocationSize	시퀀스 한번 호출에 증가하는 수 성능최적화에 사용되며 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야 한다.	50
catalog	데이터베이스 catalog
schema	데이터베이스 schema

@GeneratedValue (strategy = GenerationType.TABLE)

@Id
@GeneratedValue(strategy = GenerationType.TABLE)
private Long id;

TABLE은 키 생성용 테이블을 사용한다. 시퀀스 전략을 흉내내는 전략으로 모든 DB에서 사용이 가능하다는 장점이 있다.

SEQUENCE 전략처럼 @TableGenerator 어노테이션이 필요하다.

@TableGenerator(
        name= "ZZS_SEQ_GENERATOR",
        table = "MY_SEQUENCES",
        pkColumnValue = "MEMBER_SEQ", allocationSize = 1)
public class Zangzangs{
   @Id
   @GeneratedValue(strategy = GenerationType.TABLE , generator = "ZZS_SEQ_GENERATOR")
   private Long id;
   
   ...
   ...
}

다만, 시퀀스를 값 조회보다 테이블 조회하는 성능상의 단점이 커서 일반적으로 사용하지 않는다.

@TableGenerator

속성	설명	기본값
name	식별자 생성 이름	필수
table	키생성 테이블명	hibernate_sequences
pkColumnName	시퀀스 칼럼명	sequence_name
pkColmnValue	키로 사용할 값 이름	엔티티 이름
valueColmnName	시퀀스 값 칼럼명	next_val
initialValue	초기 값, 마지막으로 생성된 값이 기준이다.	0
allocationSize	시퀀스 한 번에 호출에 증가하는 수 성능 최적화에 사용됨	50
catalog	데이터베이스 catalog
schema	데이터베이스 schema
uniqueConstraints	유니크 제약 조건을 지정한다.

@GeneratedValue (strategy = GenerationType.AUTO)

AUTO는 데이터베이스 방언에 따라 자동 지정되며, strategy 속성의 디폴트 값이다.

데이터베이스 방언에 따라 IDENTITY, SEQUENCE, TABLE 전략이 선택이 된다. 예를들어 오라클을 사용할 경우 SEQUENCE 전략이 선택된다.

JPA 버전마다 AUTO 전략이 달라질 수 있으므로 확인 후에 사용해야 한다.

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 필드와 컬럼 매핑 @Column, @Enumerated, @Temporal, @Lob

장장스 — Mon, 15 May 2023 21:03:48 +0900

[JPA] 필드와 컬럼 매핑
@Column, @Enumerated, @Temporal, @Lob, @Transient

안녕하세요? 장장스입니다.

JPA 필드와 컬럼 매핑 어노테이션에 대해 정리하겠습니다.

@Column

테이블의 컬럼 정보와 매핑하는 어노테이션이다.

속성	설명	기본값
name	필드와 매핑할 테이블의 컬럼 이름	객체의 필드 이름
insertable, updatable	insertable, updatable 가능 여부	TRUE
nullable (DDL)	null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다.
unique (DDL)	@Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제 약조건을 걸 때 사용한다.
columnDefinition (DDL)	데이터베이스 컬럼 정보를 직접 줄 수 있다. ex) varchar(100) default ‘EMPTY'	필드의 자바 타입과 방언 정보를 사용해
length (DDL)	문자 길이 제약조건, String 타입에만 사용한다.	255
precision, scale (DDL)	BigDecimal 타입에서 사용한다(BigInteger도 사용할 수 있다). precision은 소수점을 포함한 전체 자 릿수를, scale은 소수의 자릿수다. 참고로 double, float 타입에는 적용되지 않는다. 아주 큰 숫자나 정 밀한 소수를 다루어야 할 때만 사용한다.	precision=19, scale=2

@Temporal

날짜 타입 java.util.Date, java.util.Calendar 를 매핑할때 사용한다.

Java8 부터 지원하는 LocaDate, LocaDateTime은 최신 하이버네이트에서 자동으로 지원하기 때문에 생략 가능하다.

속성	설명	기본값
value	-TemporalType.DATE 날짜, 데이터베이스 date 타입과 매핑 (예: 2013–10–11) - TemporalType.TIME 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11) - TemporalType.TIMESTAMP 날짜와 시간, 데이터베이 스 timestamp 타입과 매핑 (예: 2013–10–11 11:11:11)

@Enumerated

자바 enum 타입을 매핑할 때 사용한다.

ORDINAL 옵션은 enum 순서를 저장하므로 enum 순서가 바뀌면 매우 위험해진다. 사용하지 않도록 하자.

속성	설명	기본값
value	- EnumType.ORDINAL enum 순서를 데이터베이스에 저장 - EnumType.STRING enum 이름을 데이터베이스에 저장

@Lob (BLOB, CLOB)

데이터베이스 BLOB, CLOB 타입과 매핑한다.

@Lob 어노테이션은 지정할 수 있는 속성이 없으며, 매핑하는 필드 타입에 따라 CLOB, BLOB을 매핑한다.

CLOB: String, char[], java.sql.CLOB
BLOB: byte[], java.sql. BLOB

@Transient

필드를 매핑하지 않을 때 사용하는 어노테이션이다. 데이터베이스에 저장하지 않으며, 조회하지도 않는다.

주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용한다.

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 데이터베이스 스키마 자동 생성 옵션 (hibernate.hbm2ddl.auto)

장장스 — Sun, 14 May 2023 00:34:46 +0900

[JPA] 데이터베이스 스키마 자동 생성 옵션 (hibernate.hbm2ddl.auto)

안녕하세요? 장장스입니다.

데이터베이스 스키마 자동 생성

JPA는 애플리케이션 실행 시점에 테이블을 자동 생성 할 수 있는 기능을 제공한다.

<!-- 필수 속성 -->
<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>

데이터베이스 방언(dialect)을 설정하여 데이터베이스에 맞는 적절한 DDL을 생성 할 수 있다.

스키마 자동 생성 hibernate.hbm2ddl.auto 속성

<property name="hibernate.hbm2ddl.auto" value="create" />

옵션	설명
create	기존테이블 삭제 후 다시 생성 (DROP + CREATE)
create-drop	create와 같으나 종료시점에 테이블 DROP
update	변경분만 반영(운영DB에는 사용하면 안됨)
validate	엔티티와 테이블이 정상 매핑되었는지만 확인
none	사용하지 않음

운영서버에서는 절대 create, create-drop, update 사용하면 안된다.

개발 초기 단계에서는 create 또는 update
개발 서버에서는 update 또는 validate
운영 서버와 스테이징에서는 validate 또는 none

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[JPA] 영속성 컨텍스트(Persistence Context)와 주요 기능

장장스 — Sat, 13 May 2023 00:02:29 +0900

[JPA] 영속성 컨텍스트(Persistence Context)와 주요 기능

안녕하세요? 장장스입니다.

오늘은 JPA 영속성 컨텍스트와 주요 기능에 대해 정리해보겠습니다.

영속성 컨텍스트(Persistence Context)란?

JPA(Java Persistence API)에서 영속성 컨텍스트(Persistence Context)란 엔티티(Entity)를 영구 저장하는 환경을 말한다.

여기서 엔티티(Entity)는 데이터베이스의 테이블에 대응하는 클래스로. JPA에서는 @Entity 어노테이션이 붙은 클래스를 엔티티라 한다.

@Entity
public abstract class Item{
    @Id @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;
    private String name;
    private int price;
    private int stockQuantity;
}

엔티티(Entity) 매니저

엔티티 매니저(Entity Manager)를 통해 영속성 컨텍스트에 접근할 수 있으며, 엔티티 매니저는 영속성 컨텍스트(Persistence Context)내에서 엔티티(Entity)를 관리한다.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("emf");
EntityManager em = emf.createEntityManager();

데이터베이스의 데이터를 변경하는 모든 명령은 트랜잭션 안에서 이루어져야 한다. 엔티티 매니저로부터 트랜잭션을 얻을 수 있다.

EntityTransaction tx = em.getTransaction();

tx.begin(); // 트랜잭션 시작
tx.commit(); // 트랜잭션 수행
tx.rollback(); // 작업에 문제 발생 시

엔티티 매니저는 데이터베이스 연결이 필요한 시점에 커넥션 풀에서 커넥션(connection)을 얻어서 사용한다.

참고로, JPA의 구현체(hibernate) 는 EntityManagerFactory를 생성할 때 커넥션 풀을 생성한다.

엔티티의 생명주기

비영속(new/transient)

영속성 컨텍스트와 상관 없이 단순히 객체를 생성한 상태를 말한다.

Member member = new Member();

영속(managed)

영속성 컨텍스트에 영속된 상태를 말한다.

em.persist(member);

준영속(detached)

영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 상태를 말한다.

em.detach(member); // 특정 엔티티를 준영속 상태로 전환
em.clear(); //영속성 컨텍스트 초기화
em.close(); //영속성 컨텍스트 종료

영속성 컨텍스트가 제공하는 기능을 사용하지 못하기 때문에 비영속 상태와 유사하다. 다만, 준영속 상태는 영속 상태였을 때의 식별자 값을 가지고 있다. 준영속 상태를 다시 영속 시키려면 merge 메서드를 사용한다.

em.merge(member);

삭제(removed)

영속성 컨텍스트를 삭제한 상태를 말한다.

em.remove(member);

1차 캐시(First Level Cache)

영속성 컨텍스트의 가장 주요 기능은 캐시 기능을 제공하는 것이다. 1차 캐시는 영속성 컨텍스트 내부에 존재하는 캐시로, 데이터베이스에서 데이터를 가져오는 것이 아닌 영속성 컨텍스트 내부에서 데이터를 가져오는 기능입니다.

1차 캐시를 사용함으로서 성능상의 이점이 발생 하지만, 1차 캐시는 동일 트랜잭션 내에서만 유지되기 때문에 보통 성능상 큰 차이가 발생하지 않는다.

동일성 보장

1차 캐시로 반복 가능한 읽기 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공한다. 따라서 자바의 컬렉션과 같이 동일 트랜잭션에서 엔티티의 동일성을 보장해준다.

Member a = em.find(Member.class, "member1"); 
Member b = em.find(Member.class, "member1");
System.out.println(a == b); //동일성 비교 true

쓰기 지연(Write Behind)

쓰기 지연(Write Behind)은 트랜잭션을 커밋할 때까지 SQL 쿼리를 모아서 한번에 DB에 전달하는 방식을 말한다.

// 1.트랜잭션 시작
transaction.begin(); 

// 2. 엔티티 영속성 컨텍스트 등록
em.persist(memberA);
em.persist(memberB);
//---여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.---

// 3. 트랜잭션 커밋 - 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit();

em.persist() 메서드가 수행되면 다음과 같은 동작이 일어난다.

1. 영속성 컨텍스트 1차 캐시에 저장
2. 쓰기 지연 SQL 저장소에 INSERT SQL 을 생성하여 보관

마지막으로 transaction.commit() or em.flush()이 실행되면 쓰기 지연 SQL 저장소의 SQL들을 한꺼번에 데이터베이스로 날린다. 쓰기 지연은 일종의 버퍼링 기능으로 I/O 부하를 줄일 수 있다는 것이 장점이다.

다만, 너무 많은 I/O가 동시에 발생하면 DB에 부하를 줄 수도 있다. 하이버네이트에서는 최대 한번에 보낼 insert/update 사이즈를 설정하는 옵션을 제공한다.

<property name="hibernate.jdbc.batch_size" value="10"/>

변경 감지(Dirty Checking)

JPA는 엔티티가 변경되면 수정 메서드를 사용하지 않아도 자동으로 UPDATE 쿼리를 날리게 된다.

// 1.트랜잭션 시작
transaction.begin();

// 2.영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");
// 3. 영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);

// 3-1. em.update(member) 이런 코드가 있어야 하지 않을까?

// 4. 트랜잭션 커밋
transaction.commit();

마치 자바 컬렉션에 있는 값을 꺼내서 변경하면 컬렉션에 다시 저장하지 않아도 컬렉션의 값이 수정되어 있는 것과 동일하게 동작한다. 이러한 JPA의 변경 감지(Dirty Checking)는 영속성 컨텍스트와 밀접한 관련이 있다.

transaction.commit() 명령이 호출되기 전에 em.flush() 메서드가 호출된다.

플러시(flush)

플러시가 발생하면 영속성 컨텍스트에서는 최초 데이터 1차 캐시에 저장된 상태의 스냅샷과 현재 엔티티의 값을 비교하는 동작이 수행된다. 엔티티의 값이 변경이 된 경우라면 UPDATE 쿼리를 생성하여 SQL 쓰기 지연 저장소에 저장하고, 데이터베이스에 쿼리를 보내게 된다.

영속성 컨텍스트를 플러시 하는 방법은 총 3가지 이다.

1. 직접 flush() 호출

2. transaction.commit()시 flush() 자동 호출

3. JPQL 쿼리를 실행하게 되면 flush() 자동 호출

JPQL 쿼리 실행시 flush()가 자동으로 호출되는 이유는 무엇일까?

JPQL은 영속성 컨텍스트에 적용되는 것이 아니라 데이터베이스에 직접 쿼리를 날리게 된다. 영속성 컨텍스트에 있지만 flush() 되지 않은 객체를 찾는 쿼리를 날릴 경우 객체가 DB에 없어 조회되지 않기 때문에 JPQL 쿼리를 실행하게 되면 자동으로 flush()를 자동으로 호출하게 된다.

Post

References

자바 ORM 표준 JPA 프로그래밍 - 기본편 [김영한]

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

스트림 활용하기, 중간연산과 최종연산 #filter #map #findAny #reduce

장장스 — Sun, 26 Mar 2023 15:53:22 +0900

스트림 활용하기, 중간연산과 최종연산

#filter #distinct

#takeWhile #dropWhile #skip #limit

#map #flatMap

#anyMatch #allMatch #noneMatch

#findAny #findFirst

안녕하세요? 장장스입니다.

오늘은 스트림 연산에 대해 정리해 보겠습니다.

1. 스트림 요소 필터링

filter 메서드

Stream<T> filter(Predicate<? super T> predicate);

fillter 메서드는 프레디케이트(Predicate)를 인수로 받아서 프레디케이트와 일치하는 모든 요소를 포함하는 스트림을 반환한다.

public static final List<Dish> menu = Arrays.asList(
      new Dish("pork", false, 800, Dish.Type.MEAT),
      new Dish("beef", false, 700, Dish.Type.MEAT),
      new Dish("chicken", false, 400, Dish.Type.MEAT),
      new Dish("french fries", true, 530, Dish.Type.OTHER),
      new Dish("rice", true, 350, Dish.Type.OTHER),
      new Dish("season fruit", true, 120, Dish.Type.OTHER),
      new Dish("pizza", true, 550, Dish.Type.OTHER),
      new Dish("prawns", false, 400, Dish.Type.FISH),
      new Dish("salmon", false, 450, Dish.Type.FISH)
  );

위와 같이 menu 리스트가 있을 때,

List<Dish> vegetarianMenu = menu.stream()
            .filter(Dish::isVegetarian)
            .collect(toList());

vegetarianMenu.forEach(System.out::println);

isVegetarian 메서드는 Dish 인스턴스가 채소인지 확인하는 void->boolean 형 메서드이다.

출력 결과를 보면 다음과 같다.

french fries
rice
season fruit
pizza

distinct 메서드

Stream<T> distinct();

distinct 메서드는 고유 요소를 필터링 하는 메서드이다.

고유 여부는 스트림에서 만든 객체의 hashCode, equals로 결정이 된다.

List<Integer> numbers = Arrays.asList(1, 2, 1, 3, 3, 2, 4);

위와 같이 numbers 리스트가 있을때,

numbers.stream()
       .filter(i -> i % 2 == 0)
       .distinct()
       .forEach(System.out::println);

짝수를 필터링하여 distinct 메서드를 실행하면, 다음과 같이 중복된 숫자가 제거 되어 출력된다.

2
4

2. 스트림 슬라이싱

자바 9부터는 스트림의 요소를 선택할 수 있는 takeWhile, dropWhile 메서드를 지원한다.

List<Dish> specialMenu = Arrays.asList(
        new Dish("season fruit", true, 120, Dish.Type.OTHER),
        new Dish("prawns", false, 300, Dish.Type.FISH),
        new Dish("prawns and chips", false, 320, Dish.Type.FISH),
        new Dish("rice", true, 350, Dish.Type.OTHER),
        new Dish("chicken", false, 400, Dish.Type.MEAT),
        new Dish("french fries", true, 530, Dish.Type.OTHER)
        );

위와 같은 specialMenu 리스트가 있다.

tak eWhile 메서드

takeWhile 메서드는 조건에 맞는 요소가 나왔을 때부터 반복 작업을 수행한다.

List<Dish> slicedMenu1 = specialMenu.stream()
                .takeWhile(dish -> dish.getCalories() < 320)
                .collect(toList());
                
slicedMenu1.forEach(System.out::println);

다음은 출력 결과이다.

season fruit
prawns

dropWhile 메서드

dropWhile 메서드는 takeWhile 의 정반대로 조건에 맞는 요소가 나올 때부터 반복작업을 수행한다.

List<Dish> slicedMenu2 = specialMenu.stream()
        .dropWhile(dish -> dish.getCalories() < 320)
        .collect(toList());
        
slicedMenu2.forEach(System.out::println);

다음은 출력 결과이다.

prawns and chips
rice
chicken
french fries

limit 메서드

주어진 값 이하의 크기를 갖는 새로운 스트림을 반환한다.

List<Dish> dishesLimit3 = menu.stream()
                .filter(d -> d.getCalories() > 300)
                .limit(3)
                .collect(toList());

dishesLimit3.forEach(System.out::println);

limit의 요소 3만큼 선택하여 리스트가 만들어진 것을 확인 할 수 있다.

pork
beef
chicken

skip 메서드

limit 메서드와 정반대로 처음 선택한 요소의 개수만큼을 제외한 스트림을 반환 할 수 있다.

 List<Dish> dishesSkip2 = menu.stream()
                .filter(d -> d.getCalories() > 300)
                .skip(2)
                .collect(toList());


dishesSkip2.forEach(System.out::println);

처음 요소 2개를 제외한 모든 요소가 출력이 되는 것을 확인 할 수 있다.

chicken
french fries
rice
pizza
prawns
salmon

3. 스트림 요소 매핑

map 메서드

스트림은 함수를 인수로 받는 map 메서드를 지원한다.

<R> Stream<R> map(Function<? super T, ? extends R> mapper);

인수로 제공된 함수는 각 요소에 적용되며 함수를 적용한 결과가 새로운 요소로 매핑된다.

Function은 T->R 함수형 인터페이스!

List<String> words = Arrays.asList("Hello", "World", "Stream API", "map");

List<Integer> wordLengths = words.stream()
        .map(String::length)
        .collect(toList());

System.out.println(wordLengths);

map 메서드에 인자로 들어간 length 함수의 반환값이 int 로 stream 요소의 값이 String에서 Integer로 매핑되는 것을 알 수 있다.

[5, 5, 10, 3]

flatMap

flatMap 메서드는 배열을 스트림이 아니라 스트림의 콘텐츠로 매핑한다. 하나의 평면화된 스트림을 반환한다.

List<String> words = Arrays.asList("Hello", "World", "Stream API", "map");

위 문자열 배열에서 중복을 제외한 알파벳을 뽑아보자.

words.stream()
    .map(word -> word.split(""))
    .flatMap(Arrays::stream)
    .distinct()
    .collect(toList());

flatMap 메서드는 문자열 배열(String[])을 하나의 평면화된 스트림으로 반환한다. 반환의 과정은 사진과 같다.

4.스트림 요소 매칭

anyMatch 메서드

프레디케이트로 적어도 한 요소와 일치하는지 확인하는 메서드이다.

menu.stream()
    .anyMatch(Dish::isVegetarian);

allMatch 메서드

스트림의 모든 요소가 주어진 프레디케이트와 일치하는지를 검사한다.

menu.stream()
    .allMatch(d -> d.getCalories() < 1000);

noneMatch 메서드

allMatch 메서드와 정반대 연산을 수행한다. 스트림의 모든 요소가 일치하는 요소가 없는지 확인한다.

menu.stream()
    .noneMatch(d -> d.getCalories() >= 1000);

5. 스트림 요소 검색

findAny 메서드

현재 스트림에서 임의의 요소를 반환한다. findAny 메서드를 다른 스트림연산과 연결해서 사용할 수 있다.

menu.stream()
    .filter(Dish::isVegetarian)
    .findAny();

findFirst 메서드

리스트 또는 정렬된 연속된 데이터로부터 생성된 스트트림에서 논리적인 아이템 순서가 정해져 있을 수 있다. 이런 스트림에서 첫 번째 요소를 찾아 내는 메서드이다.

menu.stream()
    .filter(Dish::isVegetarian)
    .findFirst();

6. 리듀싱 (reduce)

스트림에서는 스트림의 모든 요소를 처리해서 값으로 도출하는 리듀싱 연산을 지원한다.

reduce 메서드

reduce 연산은 초깃값과 두요소를 조합해서 새로운 값을 만드는 BinaryOperator<T>를 2개의 인수로 갖는다.

List<Integer> numbers = Arrays.asList(3, 4, 5, 1, 2);

int sum = numbers.stream().reduce(0, (a, b) -> a + b);
System.out.println(sum);

위 예제에서는 BinaryOperator 대신 람다 표현식 (a, b) -> a+b 를 사용했다.

아래는 출력 결과이다.

reduce 연산은 스트림이 하나의 값이 될때까지 각 요소를 반복해서 조합한다.

초깃값이 없는 reduce 메서드

Optional<Integer> min = numbers.stream().reduce((a,b) -> a+b);

이처럼 초깃값을 설정하지 않는 reduce도 있다. 여기서 주의할 점은 Optional을 반환하는 것이다. 예를 들어, 스트림에 아무 요소가 없는 경우 값을 반환 할 수 없다. 때문에 Optional을 감싸 값을 반환한다.

reduce를 사용한 최댓값, 최솟값

reduce연산을 활용하여 최댓값과 최솟값을 연산 할 수 있다.

Optional<Integer> min = numbers.stream().reduce(Integer::min);

Optional<Integer> min = numbers.stream().reduce(Integer::max);

Post

References

모던 자바 인 액션

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

자바 스트림 설명부터 사용하는 이유 파헤쳐보기 #JAVA #스트림

장장스 — Sun, 29 Jan 2023 16:53:38 +0900

자바 스트림 설명부터 사용하는 이유 파헤쳐보기 #JAVA #스트림

안녕하세요? 장장스입니다.

오늘은 자바 스트림에 대해서 정리해 보겠습니다.

스트림(Stream)이란 무엇인가?

스트림(Stream)은 자바 8 API에 새로 추가된 기능이다. 스트림을 이용하면 선언형(더 간결하고 가독성이 좋도록)으로 컬렉션 데이터를 처리할 수 있다.

※ JAVA Colletion Data의 상속구조

일단 스트림이 데이터 컬렉션 반복을 멋지게 처리하는 기능이라고 생각하자. 또한 스트림을 이용하면 멀티스레드 코드를 구현하지 않아도 데이터를 투명하게 병렬로 처리할 수 있다.

예를 들어, Dish 클래스의 리스트 형태인(List<Dish>) menu 리스트가 있을 때, 저칼로리 순서대로 음식명을 추출하고자 한다.

//1. low 칼로리 음식만 리스트로 추출한다.
List<Dish> lowCaloricDishes = new ArrayList<>();
for (Dish dish: menu){
    if (dish.getCalories() < 400) {
        lowCaloricDishes.add(dish);
    }
}

//2. low 칼로리 순서대로 음식을 정렬한다.
Collections.sort(lowCaloricDishes, new Comparator<Dish>() {
    @Override
    public int compare(Dish o1, Dish o2) {
        return Integer.compare(o1.getCalories(), o2.getCalories());
    }
});

//3. low 칼로리 음식의 이름만 리스트로 반환한다.
List<String> lowCaloricDishesName = new ArrayList<>();
for (Dish dish : lowCaloricDishes) {
    lowCaloricDishesName.add(dish.getName());
}

먼저 저칼로리의 음식을 리스트로 추출하기 위해 lowCaloricDishes 리스트를 만들고, 칼로리 순서대로 정렬 후, 음식 이름만을 lowCaloricDishesName 리스트로 추출할 수 있다. 이때, 중간에 데이터를 담기 위한 lowCaloricDishes라는 '가비지 변수'를 사용하게 된다.

(코드가 매우 길고 보기가 좋지 않다..!)

스트림을 이용하면 아래의 코드처럼 lowCaloricDishesName리스트를 추출할 수 있다.

List<String> lowCaloricDishesName =
    menu.stream()
        .filter(d -> d.getCalories() < 400)
        .sorted(Comparator.comparing(Dish::getCalories))
        .map(d -> d.getName())
        .collect(Collectors.toList());

일반적인 명령형 프로그래밍의 for문을 사용할 때와 비교하면 확실히 스트림이 더 간결하고, 가독성이 좋아진다.

그래서 스트림(Stream)이 뭔데!

스트림(Stream)은 데이터 처리 연산을 지원하도록 소스에서 추출된 연속된 요소로 정의할 수 있다.

데이터 처리 연산

스트림은 함수형 프로그래밍 언어에서 일반적으로 지원하는 연산과 데이터베이스와 비슷한 연산을 지원한다. 예를 들어 filter, map, reduce, find, match, sort 등으로 데이터를 조작할 수 있다. 스트림 연산은 데이터를 순차적으로 또는 병렬로 실행할 수 있다.

소스

스트림은 컬렉션, 배열, I/O 자원 등의 데이터 제공 소스로부터 데이터를 소비한다. 정렬된 컬렌션으로 스트림을 생성하면 정렬이 그대로 유지된다. 즉, 리스트로 스트림을 만들면 스트림의 요소는 리스트의 요소와 같은 순서를 유지한다.

연속된 요소

컬렉션과 마찬가지로 스트림은 특정 요소 형식으로 이루어진 연속된 값 집합의 인터페이스를 제공한다. 컬렉션은 자료구조이므로 컬렉션에서는 시간과 공간의 복잡성과 관련된 요소 저장(ex: add) 및 접근(ex: get) 연산이 주를 이룬다. 반면, 스트림은 filter, map, sorted처럼 표현 계산식이 주를 이룬다. 정리하면, 컬렉션의 주제는 데이터이고, 스트림의 주제는 계산이다.

스트림(Stream)의 특징

파이프 라이닝

부분의 스트림 연산은 스트림 연산끼리 연결해서 커다란 파이프 라인을 구성할 수 있도록 스트림 자신을 반환한다. 그 덕분에 layziness(게으름), short-circuiting(쇼트서킷) 같은 최적화도 얻을 수 있다. 연산 파이프라인은 데이터 소스에 적용하는 데이터베이스 질의와 비슷하다.

layziness(게으름)은 최종연산이 실행되기 전까지 중간연산(filter, sorted, map, ..)이 실행되지 않는 것을 말한다.

short-circuiting(쇼트서킷)은 여러 개의 조건이 중첩된 상황에서 값이 결정 나면 더 이상 불필요한 실행을 하지 않도록 하여 실행 속도를 올리는 기법을 말한다.

내부 반복

반복자를 이용해서 명시적으로 반복하는 컬렉션과 달리 스트림은 내부 반복을 지원한다.

컬렉션과 스트림

데이터를 언제 계산하느냐가 컬렉션과 스트림의 가장 큰 차이이다.

컬렉션은 우리가 아는 DVD와 비슷하다. 영상 전체 데이터를 CD에 모두 담고 있다. 컬렉션은 현재 자료구조가 포함하는 모든 값을 메모리에 저장하는 자료 구조다. 즉, 컬렉션의 모든 요소는 컬렉션에 추가하기 전에 계산되어야 한다.

반면, 스트림은 스트리밍 서비스와 비슷하다. 사용자가 필요로 하는 몇 부분만 미리 내려받는다. 스트림은 이론적으로 요청할 때만 요소를 계산하는 고정된 자료구조이다. 사용자가 요청하는 값만 추출하는 것이 스트림의 핵심이다.

또 다른 컬렉션과 스트림의 차이점은 외부 반복과 내부 반복이다.

컬렉션을 사용하려면 사용자가 직접 요소를 반복(ex: for-each문)해야 하는데 이를 외부 반복이라 한다. 반면 스트림은 반복을 알아서 처리하고 결과 스트림 값을 어딘가에 저장해 주는 내부 반복을 사용한다.

예제를 들어 조금 더 자세히 알아보자. 수학점수와 학년을 변수로 갖는 Score 리스트가 있다.

public static final List<Score> scores = Arrays.asList(
    new Score(100, GRADE.GRADE4)
    ,new Score(80, GRADE.GRADE1)
    ,new Score(17, GRADE.GRADE3)
    ,new Score(50, GRADE.GRADE4)
    ,new Score(28, GRADE.GRADE3)
    ,new Score(30, GRADE.GRADE2)
    ,new Score(98, GRADE.GRADE1)
    ,new Score(69, GRADE.GRADE4)
    ,new Score(87, GRADE.GRADE3)
    ,new Score(76, GRADE.GRADE2)
);

// Score 클래스 일부 소스코드
public static class Score{
    private int math;
    private GRADE grade;

    public Score(int math, GRADE grade) {
        this.math = math;
        this.grade=grade;
    }

    @Override
    public String toString() {
        return "Score{" +
                "math=" + math +
                ", grade=" + grade +
                '}';
    }
}

List<Score> 에서 학년이 4학년인 학생들의 수학 점수를 추출하려고 한다. 스트림을 활용한 아래의 코드가 실행되면 출력이 어떻게 될까?

scores.stream()
    .filter(g -> {
        System.out.println("filter 연산 : " + g.toString());
        return g.getGrade().equals(GRADE.GRADE4);
    })
    .map(m -> {
        System.out.println("map 연산  : " + m.toString());
        return m.getMath();
    })
    .limit(2)
    .forEach(System.out::println);

정답을 생각해 보면 4학년 학생의 수학점수 100, 50이 출력이 될 것이다. 그리고 중간연산 filter, map의 print문을 한번 살펴보자. 출력 결과는 아래와 같다.

filter 연산 : Score{math=100, grade=GRADE4}
map 연산  : Score{math=100, grade=GRADE4}
100
filter 연산 : Score{math=80, grade=GRADE1}
filter 연산 : Score{math=17, grade=GRADE3}
filter 연산 : Score{math=50, grade=GRADE4}
map 연산  : Score{math=50, grade=GRADE4}
50

List<Score>에는 10개의 데이터가 있었지만 모두 실행되지 않았다. 출력 내용을 하나씩 살펴보자.

Score(100, GRADE.GRADE4)인 학생은 4학년에 해당되므로 중간연산 filter, map의 출력문이 실행되고, forEach문이 실행되었다.

filter 연산 : Score{math=100, grade=GRADE4}
map 연산  : Score{math=100, grade=GRADE4}
100

Score(80, GRADE.GRADE1)인 학생은 1학년이므로, filter의 출력문만 실행되었다.

filter 연산 : Score{math=80, grade=GRADE1}

Score(17, GRADE.GRADE3)인 학생은 3학년이므로, filter의 출력문만 실행되었다.

filter 연산 : Score{math=17, grade=GRADE3}

Score(50, GRADE.GRADE4)인 학생은 4학년에 해당되므로 중간연산 filter, map의 출력문이 실행되고, forEach문이 실행되었다.

filter 연산 : Score{math=50, grade=GRADE4}
map 연산  : Score{math=50, grade=GRADE4}
50

그 이후의 데이터는 limit(2)를 만족하는 결과를 얻었기 때문에 연산이 수행되지 않았다.

스트림 연산

스트림의 연산은 크게 중간 연산과 최종 연산으로 나눈다. 스트림은 왜 연산을 두 가지로 구분하는 것일까?

중간 연산

filter나 sorted 같은 중간 연산은 다른 스트림을 반환한다. 따라서 다양한 중간연산을 연결하여 질의를 만들 수 있다.(루프 퓨전[loop fusion]이라 한다)

중간 연산의 중요한 특징은 단말 연산을 스트림 파이프라인에 실행하기 전까지는 아무 연산도 수행하지 않는다는 것이다. 즉, 게으름(lazy) 특성을 같는다. 중간 연산을 합친 다음에 합쳐진 중간 연산을 최종 연산으로 한 번에 처리하기 때문이다.

위에서 사용했던 예제 코드를 다시 살펴보자.

scores.stream()
    .filter(g -> {
        System.out.println("filter 연산 : " + g.toString());
        return g.getGrade().equals(GRADE.GRADE4);
    })
    .map(m -> {
        System.out.println("map 연산  : " + m.toString());
        return m.getMath();
    })
    .limit(2)
    .forEach(System.out::println);

스트림의 게으름(layziness) 특성 덕분에 List <score>의 개수는 10개이지만 단말연산 limit(2) 덕분에 처음 2개의 결과가 나올 때까지만 반복이 수행되었다.

중간 연산 filter, map이 서로 다른 연산이지만 한 과정으로 병합되어 수행되었는데, 이를 루프 퓨전(loop fusion)이라 한다.

최종 연산

최종 연산은 스트림 파이프라인에서 결과를 도출한다. 보통 최종 연산에 의해 List, Integer, void 등 스트림 이외의 결과가 반환된다. 예제 코드의 파이프라인에서 forEach는 void를 반환하는 최종 연산이다.

Post

자바 람다 표현식 설명부터 사용법까지 완벽 정리 #JAVA #람다

References

모던 자바 인 액션

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

자바 람다 표현식 설명부터 사용법까지 완벽 정리 #JAVA #람다

장장스 — Tue, 3 Jan 2023 00:20:25 +0900

자바 람다 표현식 설명부터 사용법까지 완벽 정리 #JAVA #람다

안녕하세요? 장장스입니다.
오늘은 자바 8에 추가된 람다에 대해 정리하겠습니다.

람다란 무엇인가?

람다 표현식은 메서드로 전달할 수 있는 익명 함수를 단순화한 것이라고 할 수 있습니다. 람다 표현식에는 이름은 없지만, 파라미터 리스트, 바디, 반환 형식, 발생할 수 있는 예외 리스트를 가질 수 있습니다.

람다의 특징을 하나씩 살펴보면,

▶ 익명
보통의 메서드와 달리 이름이 없으므로 익명이라 표현한다. 구현해야 할 코드가 줄어든다.

▶ 함수
람다는 메서드처럼 특정 클래스에 종속되지 않으므로 함수라고 부른다. 하지만 메서드처럼 파라미터 리스트, 바디, 반환 형식, 가능한 예외 리스트를 포함한다.

▶ 전달
람다 표현식을 메서드 인수로 전달하거나 변수로 저장할 수 있다.

▶ 간결성
익명 클래스처럼 많은 자질구레한 코드를 구현할 필요가 없다.

익명 클래스란?

말 그대로 이름이 없는 클래스로, 일시적으로 만들어서 사용되고 버려지는 클래스를 말한다.
Comparator 클래스를 직접 구현하여 사용 하는 것을 예로 들 수 있다.
Comparator<Tiger> comparator = new Comparator<Tiger>() {
  @Override
  public int compare(Tiger t1, Tiger t2) {
    return Integer.compare(t1.getWeight(), t2.getWeight());
  }
};

위의 익명 클래스를 이용한 코드를 람다를 사용하면 아래처럼 바꿀 수 있다.

Comparator<Tiger> byWeight = 
    (Tiger t1, Tiger t2) -> t1.getWeight() - t2.getWeight();

람다 표현식은 람다 파라미터, 화살표, 람다 바디로 구성된다.

람다는 어디에 어떻게 쓰일까?

그래서 람다 표현식은 어디에 어떻게 쓰는지에 대한 궁금증이 생긴다. 함수형 인터페이스라는 문맥에서 람다 표현식을 사용할 수 있다.

함수형 인터페이스(Functional Interface)?

함수형 인터페이스(Functional Interface)는 정확히 하나의 추상 메서드를 지정하는 인터페이스다. 위에서 사용했던 Comparator도 자바 API의 함수형 인터페이스이다.

※ 함수형 인터페이스는 @FunctionalInterface 어노테이션을 사용해서 표기한다.
필수적으로 구현해야 하는 추상 메서드가 1개 있으며, @FunctionalInterface 로 선언했지만 실제로 함수형 인터페이스가 아닌경우 컴파일 에러를 발생할 수 있다.

위에서 예시로 사용했던 함수형 인터페이스 Comparator는 추상 메서드 compare를 직접 구현하여야 한다.

람다 표현식으로 함수형 인터페이스의 추상 메서드 구현을 직접하여 전달할 수 있으므로 전체 표현식을 함수형 인터페이스의 인스턴스로 취급할 수 있다. (자바 문법으로는 함수형 인터페이스를 구현한 클래스의 인스턴스이다.)

함수 디스크립터(function descriptor)

람다 표현식의 시그니처를 서술하는 추상 메서드를 함수 디스크립터(function descriptor)라고 부른다. 람다 표현식의 시그니처는 함수형 인터페이스의 추상 메서드 시그니처와 동일하다.

예를 들어, Comparator 인터페이스의 메서드 compare가 두개의 인수를 받아 int를 반환하므로 Comparator 인터페이스는 두개의 인수를 받아 int를 반환하는 시그니처로 볼 수 있다.

다른 예로, Runnable 인터페이스의 추상 메서드 run은 파라미터를 받지 않고 void를 반환하므로 Runnable 인터페이스의 시그니처는 파라미터를 받지 않고 void를 반환 하는 것으로 생각하면 된다.

확인된 예외(Exception)을 던지지 않는 함수형 인터페이스

메서드를 만들때 우리는 확인된 예외(Exception)를 던지는 일을 한다. 아래 예시를 보면, BufferedReader 클래스의 readLine 함수를 사용했을 때, IOException이 예상이 된다.

public void printInputText() throws IOException {
    BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in));
    String s = bufferedReader.readLine();
    System.out.printf("inputText : %s", s);
}

그러나 람다는 확인된 예외를 던지기 위해서는 확인된 예외를 선언하는 함수형 인터페이스를 직접 정의하거나, 람다를 try~catch문을 사용하여 감싸야한다.

1. 확인된 예외를 선언하는 함수형 인터페이스 정의
BufferedReader를 사용할 때 발생할 수 있는 IOException을 선언하는 함수형 인터페이스를 직접 정의하여 사용 할 수 있다.

@FunctionalInterface
public interface BufferedReaderProcessor{
    String process(BufferedReader bufferedReader) throws IOException;
}

BufferedReaderProcessor bufferedReaderProcessor =
        (BufferedReader bufferedReader) -> bufferedReader.readLine();

String s = bufferedReaderProcessor.process(new BufferedReader(new InputStreamReader(System.in)));

2. try~catch문으로 사용하여 감싸기
BufferedReader를 사용할 때 발생할 수 있는 IOException을 try~catch 문으로 감싼다.

public void printInputText(){
    Function<BufferedReader, String> function = (BufferedReader br) -> {
        try {
            return br.readLine();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    };

    String s = function.apply(new BufferedReader(new InputStreamReader(System.in)));
    System.out.printf("inputText : %s", s);
}

자바8의 함수형 인터페이스

다양한 람다 표현식을 사용하려면 다양한 함수 디스크립터를 기술하는 함수형 인터페이스들이 필요하다. 자바 API는 다양한 함수형 인터페이스들을 제공한다.

함수형 인터페이스	함수 디스크립터	기본형 특화
Predicate<T>	T -› boolean	IntPredicate LongPredicate DoublePredicate
Consumer<T>	T -> void	IntConsumer LongConsumer DoubleConsumer
Function<T>	T -> R	IntFunction<R> IntToDoubleFunction IntToLongFunction LongFunction<R> LongToDoubleFunction LongToIntFunction DoubleFunction<R> DoubleToIntFunction DoubleToLongFunction ToIntFunction<T> ToLongFunction<T> ToDoubleFunction<T>
Supplier<T>	() -> T	BooleanSupplier IntSupplier LongSupplier DoubleSupplier
UnaryOperator<T>	T -> T	IntUnaryOperator LongUnaryOperator DoubleUnary0perator
BinaryOperator	(T, T) -> T	IntBinaryOperator LongBinaryOperator DoubleBinary0perator
BiPredicate<L, R>	(L, R) -> boolean
BIConsumer<T, U>	(T, U) -> void	ObjIntConsumer<T> ObjLongConsumer<T> ObjDoubleConsumer<T>
BIFunction<T, U, R>	(T, U) -> R	ToIntBiFunction<T, U> ToLongBiFunction<T, U> ToDoubleBiFunction<T, U>

람다로 함수형 인터페이스의 인스턴스는 어떻게 만드는 걸까?

람다 표현식은 함수형 인터페이스의 인스턴스를 만들 수 있다. 그러나 람다 표현식 자체에는 람다가 어떤 함수형 인터페이스를 구현하는지의 정보가 포함되어 있지 않다. 따라서 람다 표현식을 이해하려면 실제 함수형 인터페이스의 형식을 파악해야 한다.

public void filterHeavyTiger(){
    List<Tiger> heavierThen290kg = filter(tigers, (Tiger tiger) -> tiger.getWeight() > 290);
}

public static List<Tiger> filter(List<Tiger> tigers, Predicate<Tiger> predicate) {
    return tigers.stream()
             .filter(predicate)
             .collect(Collectors.toList());
}

위 코드는 호랑이 몸무게가 290kg을 넘는 호랑이를 필터링 하기 위한 filterHeavyTiger 메서드이다.

(Tiger tiger) -> tiger.getWeight() > 290

여기에 사용된 람다는 어떻게 Predicate 함수형 인터페이스인 것을 확인 할 수 있었을까?

람다의 형식 검사

람다가 사용되는 콘텍스트(context)를 이용해서 람다의 형식을 추론할 수 있다. 어떤 콘텍스트에서 기대되는 람다 표현식을 대상 형식(target type)이라고 부른다.

(Tiger tiger) -> tiger.getWeight() > 290

위 코드의 형식검사의 과정을 살펴보면 아래와 같다.

1. 람다가 사용된 콘텍스트는 무엇인가?
- filter 메서드를 확인한다.
2. 대상 형식을 확인한다.
- 두 번째 파라미터가 Predicate<Tiger> 대상 형식을 기대한다.
3. 대상 형식(Predicate<Tiger>)의 추상 메서드는 무엇인가?
- Predicate<Tiger>는 test 추상 메서드를 정의하는 함수형 인터페이스이다.
- 이해가 안가면 Predicate 인터페이스를 확인해 보자
4. Tiger를 인수로 받아 boolean을 반환하는 test 메서드다.
- test 메서드는 Tiger를 받아 boolean을 반환하는 함수 디스크립터를 묘사한다.
5. 함수 디스크립터와 람다의 시그니처와 일치를 확인한다.
- 형식 검사가 완료 된다.

대상 형식(Target Type)이라는 특징 때문에 같은 람다 표현식이더라도 호환되는 추상 메서드를 가진 다른 함수형 인터페이스로 사용될 수 있다.

Callable<Integer> c         = () -> 7;

PrivilegedAction<Integer> p = () -> 7;

Callable과 PrivilegedAction는 파라미터를 받지 않고, 제네릭 형식 T를 반환하는 함수를 정의한다. 따라서 위 코드는 모두 유효한 코드이다.

형식 추론

자바 컴파일러는 대상 형식(콘텍스트)을 이용해서 함수 디스크립터를 알 수 있으므로 컴파일러는 람다의 시그니처도 추론할 수 있다. 결과적으로 컴파일러는 람다 표현식의 파라미터 형식에 접근할 수 있으므로 람다 문법에서 이를 생략할 수 있다. 즉, 자바 컴파일러는 다음 처럼 람다 파라미터 형식을 추론할 수 있다.

Comparator<Tiger> c1 = (Tiger t1, Tiger t2) -> t1.getWeight().compareTo(t2.getWeight());

Comparator<Tiger> c2 = (t1, t2) -> t1.getWeight().compareTo(t2.getWeight());

어떤 코드가 더 좋다라고는 할 수 없다. 상황에 따라 형식을 배제하는 것이 가독성을 향상 시킬 수도 있고, 떨어지게 할 수도 있다. 이는 개발자 스스로 어떤 코드가 가독성을 향상시킬 수 있을지 결정해야 한다.

람다의 제약

지금까지 람다 표현식 설명을 위해 사용한 코드들을 보면 람다 표현식은 인수를 자신의 바디 안에서만 사용했다. 하지만 람다 표현식에서는 익명 함수가 하는 것처럼 자유 변수를 활용할 수 있다. 이와 같은 동작을 람다 캡처링이라고 부른다.

int waitNumber = 102;
Runnable r = () -> System.out.println(waitNumber);

위의 코드는 유효한 코드로 정상 동작한다. 그렇다면 다음 코드는 어떻게 될까?

int waitNumber = 102;
Runnable r = () -> System.out.println(waitNumber);
waitNumber = 500;

이 코드는 컴파일 에러가 발생한다.

람다 표현식에서 자유 변수에 제약이 있다. 람다는 인스턴스 변수와 정적 변수를 자유롭게 캡처할 수 있다. 하지만 지역 변수는 명시적으로 final로 선언 되어 있어야 하거나 실질적으로 final로 선언된 변수와 똑같이 사용되어야 한다. 즉, 람다 표현식은 한번만 할당할 수 있는 지역 변수를 캡처할 수 있다.

람다에는 왜 이런 제약이 걸리는걸까?

자바에서 인스턴스 변수는 힙 메모리에 저장된다. 반면 지역 변수는 스택 메모리에 저장된다.
람다가 스레드에서 실행되면 변수를 할당한 스레드가 사라져서 지역 변수의 할당이 해제되었는데도 람다를 실행하는 스레드에서는 해당 지역 변수에 접근하려 할 수 있다. 따라서 자바 구현에서는 원래 변수에 접근을 허용하지 않고 자유 지역 변수의 복사본을 제공한다.
따라서 복사본의 값이 바뀌지 않아야 하므로 자유 지역 변수에는 한번만 값을 할당해야 한다는 제약이 생긴 것이다.

메서드 참조

자바에는 메서드 참조 기능이 있다. 메서드 참조는 특정 메서드만을 호출하는 람다의 축약형이라고 생각할 수 있다. 예를 들어 람다가 '이 메서드를 직접 호출해' 라고 명령한다면 메서드를 어떻게 호출해야 하는지 설명을 참조하기보다는 메서드명을 직접 참조하는 것이 편리하다.

이때 명시적으로 메서드명을 참조함으로써 가독성을 높일 수 있다.

tigers.sort(Comparator.comparing(Tiger::getWeight));

메서드명 앞에 구분자 (::)를 붙이는 방식으로 메서드 참조를 활용할 수 있다. 예를 들어 Tiger::getWeight는 Tiger 클래스에 정의된 메서드 참조다.

메서드 참조를 만드는 방법

메서드 참조는 세 가지 유형으로 구분할 수 있다.
1. 정적 메서드 참조
예를 들어, Integer의 parseInt 메서드는 Integer::parseInt로 표현할 수 있다.

2. 다양한 형식의 인스턴스 메서즈 참조

예를 들어, String의 length 메서드는 String::length로 표현할 수 있다.

3. 기존 객체의 인스턴스 메서드 참조

예를 들어, Tiger 객체를 할당 받은 tiger 인스턴스트에 getWeight 메서드가 있다면, tiger::getWeight 메서드로 사용할 수 있다.

생성자 참조

생성자(new) 또한 메서드 참조를 이용해서 만들 수 있다.

인수가 없는 생성자, Supplier의 () -> Tiger 와 같은 시그니처를 갖는 생성자가 있다고 가정하면, 아래와 같이 사용 할 수 있다.

Post

자바 스트림 설명부터 사용하는 이유 파헤쳐보기 #JAVA #스트림

References

모던 자바 인 액션

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[스프링 부트] 예외처리(Exception) @ControllerAdvice @RestControllerAdvice @ExceptionHandler @ResponseStatus

장장스 — Mon, 14 Feb 2022 14:16:49 +0900

[스프링 부트] 예외처리(Exception)

@ControllerAdvice @RestControllerAdvice @ExceptionHandler @ResponseStatus

안녕하세요? 장장스입니다!

오늘은 스프링에서 '예외 처리를 어떻게 할 것인가'에 대한 포스팅을 하려고 합니다.

코드를 작성하며 고민 되는 문제 중 하나가 어떻게 예외 처리를 해야 하는가 입니다.

Exception In Java

Java Exception Hierarchy

예외 계층 구조에서 볼 수 있듯이 Java에서 발생하는 오류는 Error 클래스와 Exception 클래스로 나뉩니다. 모든 오류 및 예외는 Throwable 클래스를 상위 클래스로 가집니다. Throwable를 상속받은 하위 클래스의 인스턴스들은 JVM 또는 Java throw 문에 의해 throw됩니다.

그렇다면 Error 클래스와 Exception 클래스의 차이는 무엇일까?

오류 (Error)

오류는 처리할 수 없는 심각한 오류를 나타내는 클래스입니다. 실행 중에 throw되었지만 catch되지 않은 오류에 대해 Error 또는 해당 하위 클래스에 대해 throw 절을 선언할 필요가 없습니다. 오류는 개발자가 처리 할 수 없는 경우입니다. 예를 들어, 프로그램 실행 도중 메모리 공간 부족으로 오류가 발생하는 경우 개발자는 이를 제어 할 수 없습니다. 오류 클래스의 종류로는 OutOfMemoryError, AssertionError, StackOverflowError, IOError, NoClassDefFoundError 등이 있습니다.

예외 (Exception)
예외는 프로그램이 복구할 수 있고 응용 프로그램에서 개발자가 처리해야 하는 문제를 나타냅니다. 예외에는 두 가지 하위 유형이 있습니다.

1. Checked Exception

코드를 작성하다 보면 위 사진처럼 빨간색 밑줄이 생기는 경우를 경험한 적이 있을 것입니다. 컴파일 타임에 확인되는 이러한 예외를 Checked Exception이라고 합니다. 개발자는 이러한 예외에 대한 처리를 해야 합니다.

IOException, SQLException, FileNotFoundException, ClassNotFoundException, NoSuchMethodException 등이 Checked Exception에 해당합니다.

2.Unchecked Exception

Checked Exception과 달리 Unchecked Exception은 컴파일 타임에 확인 할 수 없습니다. 이러한 예외는 런타임에 발생합니다. 때문에 RunTimeException이라고 부르기도 합니다.

개발자는 Unchecked Exception을 발견하거나 예상된다면 해당 예외에 대한 처리를 해야 합니다.

NullPointerException, ArithmeticException, IllegalArgumentException, IndexOutOfBoundException 등이 Unchecked Exception에 해당합니다.

Unchecked Exception 처리

그렇다면 이러한 예외를 어떻게 처리할 수 있을까요? 회원가입을 예시로 들어보겠습니다. 다음과 같은 Member Entity가 있습니다.

import javax.persistence.*;

@Entity
public class Member {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "member_name", unique = true)
    private String name;

    private int age;

    protected Member() {
    }

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

'장장스'라는 이름으로 회원가입을 신청했습니다. 성공했습니다!

회원 가입을 요청하면 MemberService의 saveMember 메서드로 회원 가입을 시도합니다.

@Service
@Transactional(readOnly = true)
public class MemberService {
    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Transactional
    public Long saveMember(MemberDto memberDto){
        duplicatedMemberByName(memberDto.getName());
        return memberRepository.save(memberDto.convertEntity());
    }
}

며칠 뒤 또 다른 사람이 '장장스'라는 이름으로 회원가입을 시도했으나 에러가 발생했습니다.

회원 테이블을 확인해 보니 name 칼럼에 unique 제약 조건이 걸려 있습니다. 때문에 같은 이름으로 회원 가입을 시도하면 SQL관련된 Exception이 발생한 것입니다.

이처럼 중복된 이름으로 가입을 하는 것은 런타임에 발생할 수 있는 예상되는 Unchecked Exception 입니다. 이처럼 예상되는 문제에 대해서는 개발자가 처리를 해야 합니다.

Exception 클래스 생성하기

※ 자세한 코드는 Git을 참고해주세요 :)

먼저 RuntimeException을 상속받은 새로운 DuplicatedMemberNameException 클래스를 생성합니다.

public class DuplicatedMemberNameException extends RuntimeException{
    public DuplicatedMemberNameException() {
        super("중복된 회원입니다");
    }
}

MemberService에 새로운 메서드를 추가합니다. findMemberByName 는 name을 기준으로 회원을 찾는 메서드 이고, DuplicatedMemberNameException 는 이름이 중복될 경우 DuplicatedMemberNameException 예외를 터뜨리는 메서드입니다.

@Service
@Transactional(readOnly = true)
public class MemberService {
    
    ...생략

    public Optional<Member> findMemberByName(String name){
        return memberRepository.findByName(name);
    }

    private void duplicatedMemberByName(String name){
        if(findMemberByName(name).isPresent()){
            throw new DuplicatedMemberNameException();
        }
    }
}

이제 같은 이름으로 가입을 진행하면 SQL 관련 Exception이 아니라 DuplicatedMemberNameException 예외가 터지게 됩니다.

간단한 테스트 코드를 작성해서 확인해 볼 수 있습니다!

@SpringBootTest
class MemberServiceTest {

    @Autowired
    private MemberService memberService;


    @Test
    @DisplayName("회원_중복_테스트")
    @Transactional
    void duplicatedUserTest(){
        // given
        String name = "홍길동";
        int age = 15;
        MemberDto memberDto = new MemberDto(name, age);

        // when
        memberService.saveMember(memberDto);

        // then - 홍킬동 중복 가입 시도
        DuplicatedMemberNameException e = assertThrows(DuplicatedMemberNameException.class,
                () -> memberService.saveMember(memberDto));

        System.out.println("회원 중복 테스트" + e.getMessage());
    }
}

e.getMessage() 를 통해 DuplicatedMemberNameException에서 설정한 메시지를 확인 할 수 있게 되었네요.

이렇게 예측되는 예외에 대해 새로운 코드를 작성했지만 하지만 결국 Exception이 발생하는 것은 똑같습니다. DuplicatedMemberNameException이 발생하면 문제가 되는 것은 동일하니까요. 사용자는 결국 에러 페이지를 만날 수 밖에 없습니다.

@ControllerAdvice 사용하기

@ExceptionHandler 어노테이션을 사용해서 컨트롤러에서 발생하는 예외를 처리 할 수 있다. 컨트롤러에서 발생하는 예외를 처리해주는 기능을 한다. @Controller, @RestController 모두 해당된다.

@RestController
public class MemberController {

	...생략

    @PostMapping
    @ExceptionHandler(DuplicatedMemberNameException.class)
    public Object saveMember(@RequestBody MemberDto memberDto){
        return memberService.saveMember(memberDto);
    }
}

하지만 모든 컨트롤러마다 @ExceptionHandler 을 선언한다면 관리가 복잡해지게 된다. @ControllerAdvice 는 @Controller, @RestController가 적용된 Bean내에서 발생하는 예외를 처리할 수 있게 한다.

다음은 @RestController 를 처리하기 위해 작성한 ExceptionLabRestControllerAdvice 클래스이다.

@RestControllerAdvice
public class ExceptionLabRestControllerAdvice {

    Logger logger = LoggerFactory.getLogger(ExceptionLabRestControllerAdvice.class);

	..생략

    @ExceptionHandler(DuplicatedMemberNameException.class)
    @ResponseStatus(HttpStatus.CONFLICT)
    public String duplicatedMemberNameExceptionHandler(DuplicatedMemberNameException e){
        logger.error("DuplicatedMemberNameException: {}", e.getMessage());
        return e.getMessage();
    }
}

@RestControllerAdvice 을 통해 예외 처리의 타겟을 어노테이션으로 할지, 패키지나 클래스로 설정할 수 있다.

@RestControllerAdvice(annotations = RestController.class)

@RestControllerAdvice( basePackages = {"com.example.package1","com.example.package2"})

@RestControllerAdvice( basePackageClasses = MemberController.class)

@ExceptionHandler 은 어떤 Exception을 처리할지 설정 할 수 있다. 만약 value값이 없다면(Exception 클래스를 지정하지 않는경우) 메서드의 입력 파라미터의 Exception을 처리한다.

추가로, 다음과 같이 여러개의 예외를 처리할 수 있습니다.

  @ExceptionHandler({Exception1.class, Exception2.class})

@ResponseStatus 은 응답 Http 코드를 선언할 수 있다. 스프링에서 HttpStatus enum 클래스를 정의하고 있다. http 코드별 내용은 여기에서 확인 할 수 있습니다.

PostMan 을 통해 확인하기

첫 회원 가입 요청은 당연히 성공할 겁니다. 회원번호(PK)를 반환한 것을 확인 할 수 있습니다.

두 번째 요청은 회원 가입이 되지 않고, DuplicatedMemberNameException 클래스에 선언한 텍스트가 반환됨을 확인 할 수 있다. 서버에서 log도 정상적으로 출력 되는 것을 확인 할 수 있습니다.

※ 자세한 코드는 Git을 참고해주세요 :)

Post

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[DB] 트랜잭션 격리수준 (Isolation Level)

장장스 — Mon, 31 Jan 2022 19:00:04 +0900

트랜잭션 격리수준 (Isolation Level)

동시성(Concurrency) 문제

실제 서비스에서는 많은 사용자가 동시 다발적으로 서버에 요청을 하게 되고 서버는 데이터베이스에 다시 트랜잭션을 요청하게 됩니다. 모든 요청을 순서대로 처리하게 된다면 동시성(Concurrency) 문제가 생길 것입니다. 반대로 동시성을 보장하기 위해 모든 요청을 동시에 처리하려고 한다면 데이터의 값이 맞지 않는 일관성(Consistency) 문제가 생기게 됩니다.

Isolation 이 낮다면 발생하는 문제들

아래와 같은 회원 테이블이 있습니다. 이 테이블에 대한 트랜잭션이 동시에 일어나면 어떤 문제가 있을까

회원 테이블
이름	VARCHAR	장장스
잔액	BIGINT	10000
등급	VARCHAR	BRONZE
지역	VARCHAR	서울

1) Dirty Read가 발생하는 경우

아직 커밋되지 않은 데이터를 수정하는 도중 다른 트랜잭션에서 READ를 허용할 때 발생한다.

트랜잭션 (T1)	트랜잭션 (T2)
SELECT 잔액 FROM 회원 테이블 WHERE 이름=장장스;
UPDATE 회원 테이블 SET 잔액 = 9000 WHERE 이름=장장스;
	SELECT 잔액 FROM 회원 테이블 WHERE 이름=장장스;
ROLLBACK;

트랜잭션(T1)이 회원 테이블에 접근하여 잔액을 10,000에서 9,000으로 변경 했습니다. COMMIT을 하지 않았습니다. 그런데 다른 트랜잭션(T2)이 회원 테이블에 접근하여 잔액을 READ해 보니 9,000원 입니다. 트랜잭션(T1)은 수정사항을 COMMIT 하지 않고 ROLLBACK 했습니다. 따라서 장장스의 잔액은 10,000원입니다. 그러나 트랜잭션(T2) 가 조회한 잔액은 9,000원으로 데이터가 다릅니다.

2) Non-Repeatable Read가 발생하는 경우

트랜잭션 내에서 같은 내용의 쿼리가 반복해서 수행할 때, 다른 트랜잭션이 값을 수정 또는 삭제함으로써 두 쿼리가 상이하게 나타나는 비 일관성(Consistency)이 발생한다

트랜잭션 (T1)	트랜잭션 (T2)
SELECT 잔액 FROM 회원 테이블;
	UPDATE 회원 테이블 SET 잔액 = 5000 WHERE 이름=장장스;
	COMMIT;
IF 잔액 >= 10000 UPDATE 회원 테이블 SET 등급 = SILVER
COMMIT;

트랜잭션(T1)이 회원 테이블을 READ하고 있었습니다. 이때 트랜잭션(T2)가 데이터에 접근하여 값을 변경(삭제) 후 COMMIT을 했습니다. 트랜잭션(T1)이 다시 해당 데이터를 READ 하려 하는데 데이터가 변경(삭제) 되어 찾을 수가 없습니다.

3) Phantom Read

하나의 트랜잭션에서 일정범위의 레코드를 두 번 이상 읽을 때, 첫 번재 쿼리에서 없던 유령 레코드가 두번째 쿼리에서 나타나는 현상을 발생한다.

트랜잭션 (T1)	트랜잭션 (T2)
INSERT INTO 지역별 회원 테이블 *SELECT 지역, COUNT() FROM 회원 테이블 GROUP BY 지역;**
	INSERT INTO 회원 테이블(이름, 잔액, 등급, 지역) VALUES('강건마', 500, 'BRONZE', '부산');
	COMMIT;
INSERT INTO 등급별 회원 테이블 *SELECT 등급, COUNT() FROM 회원 테이블 GROUP BY 등급;**
COMMIT;

트랜잭션(T1)이 지역별, 등급별 회원을 집계하는 도중 트랜잭션(T2)가 새로운 회원을 등록하게 되었다.

그 결과 지역별 회원 테이블과 등급별 회원 테이블의 총 인원수가 불일치하게 된다.

트랜잭션 격리수준 (Isolation Level)

이처럼 동일성(Concurrency)을 높이다 보면 일관성(Consistency) 문제가 발생하는 것을 알 수 있습니다. 이러한 문제 해결을 위한 방법으로 트랜잭션 격리수준을 설정할 수 있습니다.

[Level 0] READ UNCOMMITTED

트랜잭션에서 처리 중인, 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용
Dirty Read, Non-Repeatable Read, Phantom Read 가 발생합니다.
참고로 Oracle의 경우 Read Uncommitted 레벨은 지원하지 않습니다.

[Level 1] READ COMMITTED

트랜잭션이 커밋되어 확정된 데이터만 읽는 것을 허용합니다.
DB2, SQL Server, Sybase같이 대부분의 DBMS가 기본모드로 채택하고 있습니다. READ 경우 '공유 Lock'을 이용해서 구현합니다. 하나의 레코드를 읽을 때 Lock을 설정하고 해당 레코드를 빠져 나가는 순간 Lock 해제합니다.
Dirty Read 를 방지할 수 있으나 Non-Repeatable Read, Phantom Read는 발생합니다.
Oracle database 11g의 기본 Isolation level 입니다. Oracle database는 원본 레코드를 사용하지 않고 읽기 전용 데이터 셋을 (read-consistent set of data)생성하여 사용합니다. 사용자가 데이터를 수정할 때면 COMMIT 이전까지의 변경사항을 "Undo Segments" 기록하는 방법으로 일관성을 보장합니다.

[Level 2] REPEATABLE READ

선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때가지 다른 트랜잭션이 갱신하거나 삭제하지 못하도록 하여 같은 데이터를 두 번 쿼리했을 때 일관성 있는 결과를 리턴하도록 합니다.
Dirty Read, Non-Repeatable Read를 방지할 수 있으나 Phantom Read는 발생합니다.
InnoDB 스토리 엔진을 사용하는MySQL, MariaDB의 기본 Isolation level 입니다.

[Level 3] SERIALIZABLE

선행 트랜잭션이 읽은 데이터를 다른 트랜잭션이 수정/삭제하지 못할 뿐만 아니라 중간에 새로운 레코드를 산입하지 못하도록 막아 완벽하게 읽기 일관성 모드를 제공합니다.

Post

2021.11.23 - [database/DB Concept] - [DB] 트랜잭션

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

Logback이란? feat.SLF4J

장장스 — Sun, 30 Jan 2022 18:51:08 +0900

Logback이란? feat.SLF4J

Logback?

logback은 SLF4J의 구현체입니다. logback-core, logback-classic 및 logback-access의 세 가지 모듈로 구분됩니다.

Logger, Appenders and Layouts

Logger클래스는 logback-classic 모듈의 일부입니다 . 반면에 Appender및 Layout인터페이스는 logback-core의 일부입니다. 범용 모듈로서 logback-core에는 로거 개념이 없습니다.

▶Logger

Logger는 가능한 모든 로그 기록을 개발자가 선택한 일부 기준에 따라 분류된다고 가정합니다.

level of request p	effective level q
	TRACE	DEBUG	INFO	WARN	ERROR	OFF
TRACE	YES	NO	NO	NO	NO	NO
DEBUG	YES	YES	NO	NO	NO	NO
INFO	YES	YES	YES	NO	NO	NO
WARN	YES	YES	YES	YES	NO	NO
ERROR	YES	YES	YES	YES	YES	NO

▶Appender

Logback은 로깅 이벤트를 작성하는 작업을 Appender 컴포넌트에 에 위임합니다. Appender는 ch.qos.logback.core.Appender 인터페이스를 구현했습니다.

ConsoleAppender, FileAppender, RollingFileAppender 3가지 대표적인 Appender를 제공합니다.

(참고로 SMTPAppender 와 같이 메일을 발송하는 Appender도 있습니다.)

ConsoleAppender

이름처럼 콘솔에 추가하거나 더 정확하게는 System.out 또는 System.err 를 이용하여 콘솔에 출력합니다.

Property Name	Type	Description
encoder	Encoder	이벤트가 기본 에 기록되는 방식을 결정합니다. 보통 패턴을 사용합니다.
target	String	문자열을 System.out, System.err로 출력합니다. 설정하지 않으면 default로 System.out으로 출력합니다.
withJansi	boolean	default로 withJansi property를false로 설정합니다. withJansi 가 true 일 경우 NSI color code들을 윈도우 기계(?) 에게 제공합니다

<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <!-- encoders are assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
    </encoder>
  </appender>

  <root level="DEBUG">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

FileAppender

로그 이벤트를 파일에 저장합니다. 대상 파일은 파일 옵션으로 지정됩니다. 파일이 이미 존재하는 경우 추가 속성 값에 따라 파일이 추가되거나 잘립니다 .

Property Name	Type	Description
append	boolean	기존 파일에 로그를 이어서 기록하는 프로퍼티로 default는 true로 설정 되어있습니다. false이면 기존 파일이 잘립니다.
encoder	Encoder	이벤트가 기본 에 기록되는 방식을 결정합니다. 보통 패턴을 사용합니다.
file	String	파일의 이름입니다. 파일이 없으면 파일을 생성합니다. 이때 파일의 경로 또한 설정해야 합니다. default 값은 없습니다. ex) ./log/error/error-${BY_DATE}.log
prudent	boolean	default 값은 false 입니다. prudent 모드에서는 다른 서버에서 실행 중인 FileAppender가 있는 경우에도 지정된 파일에 안전하게 로그 이벤트를 기록합니다.

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.FileAppender">
    <file>testFile.log</file>
    <append>true</append>
    <!-- set immediateFlush to false for much higher logging throughput -->
    <immediateFlush>true</immediateFlush>
    <!-- encoders are assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
  </appender>
        
  <root level="DEBUG">
    <appender-ref ref="FILE" />
  </root>
</configuration>

RollingFileAppender

FileAppender에서 로그 파일을 '롤오버'하는 기능으로 확장 됩니다. 롤오버를 쉽게 설명하면 특정 조건을 달성하면 파일을 이동시키는 것이다.

예를 들어, 용량이 2GB에 도달하거나, 로그 기록이 일주일이 되는 등 특정 조건이 충족되면 기록 대상을 다른 파일로 변경할 수 있습니다.

Property Name	Type	Description
append	boolean	기존 파일에 로그를 이어서 기록하는 프로퍼티로 default는 true로 설정 되어있습니다. false이면 기존 파일이 잘립니다.
encoder	Encoder	이벤트가 기본 에 기록되는 방식을 결정합니다. 보통 패턴을 사용합니다.
file	String	이벤트가 기본 에 기록되는 방식을 결정합니다. 보통 패턴을 사용합니다.
rolling Policy	Rolling Policy	롤오버가 발생할 때의 동작을 지시하는 구성 요소입니다. 3가지 정책을 제공합니다. - TimeBasedRollingPolicy - Size and time based rolling policy - FixedWindowRollingPolicy
triggering Policy	TriggeringPolicy	롤오버를 활성화할 시기를 알려주는 요소입니다. SizeBasedTriggeringPolicy 정책 한 가지로 현재 활성 파일의 크기를 확인하여 롤오버를 트리거 합니다. maxFileSize 옵션만 가지고 있습니다.
prudent	boolean

rolling Policy

TimeBasedRollingPolicy - 가장 인기 있는 정책입니다. 일별 또는 월별과 같이 시간을 기준으로 롤오버 합니다.

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <!-- daily rollover -->
    <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>
    <!-- keep 30 days' worth of history capped at 3GB total size -->
    <maxHistory>30</maxHistory>
    <totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>

Size and time based rolling policy - 파일 크기와 날짜 기반으로 동작합니다.

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
    <!-- rollover daily -->
    <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
    <!-- each file should be at most 100MB, keep 60 days worth of history, but at most 20GB -->
    <maxFileSize>100MB</maxFileSize>    
    <maxHistory>60</maxHistory>
    <totalSizeCap>20GB</totalSizeCap>
</rollingPolicy>

FixedWindowRollingPolicy - fixed window 알고리즘으로 동작합니다. 특정 인덱스를 넘기면 롤오버합니다.

<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
    <fileNamePattern>tests.%i.log.zip</fileNamePattern>
    <minIndex>1</minIndex>
    <maxIndex>3</maxIndex>
</rollingPolicy>

triggering Policy

SizeBasedTriggeringPolicy - 특정 파일 사이즈를 넘어가면 롤오버하도록 트리거 합니다.

<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> 
    <maxFileSize>5MB</maxFileSize> 
</triggeringPolicy>

▶Encoder

인코더는 이벤트를 바이트 배열로 변환하고 해당 바이트 배열을 OutputStream으로 변환합니다.

<encoder>
  <pattern>%d %-5level [%thread] %logger{0}: %msg%n</pattern>
  <outputPatternAsHeader>true</outputPatternAsHeader>
</encoder>

▶Layout

0.9.19 이전의 logback은 대부분의 Appender는 Layout에 의존하여 이벤트를 문자열로 변환하였으나 0.9.19부터 FileAppender하위 클래스는 더 이상 레이아웃을 사용하지 않습니다.

▶Filter

Filter는 삼항 논리를 기반으로 하여 조합되거나 연결되어 임의로 복잡한 필터링 정책을 구성할 수 있습니다.

필터 정보는 공식 문서에서 확인 할 수 있습니다.

Filter Name	TYPE
event	LoggingEvent
message	String
formattedMessage	String
logger	String
loggerContext	LoggerContextVO
level	int
timeStamp	long
marker	Marker
mdc	Map

<filter class="ch.qos.logback.classic.filter.LevelFilter">
   <level>WARN</level>
   <onMatch>ACCEPT</onMatch>
   <onMismatch>DENY</onMismatch>
</filter>

Spring Boot 적용하기

로깅 프레임워크인 logback-classic 모듈은 logback-classic.jar 외에도 logback-core.jar 가 필요합니다.

spring-boot-starter를 implementation 사용하고 있다면 특별한 설정 없이 사용이 가능합니다.

src/main/recources 경로에 logback 설정 파일인 logback-spring.xml 파일을 생성합니다.

logback-spring.xml의 예시 입니다. 검프의 Logging(로깅) #2 영상을 참고하여 작성하였습니다.

<?xml version="1.0" encoding="UTF-8"?>

<configuration>
    <timestamp key="BY_DATE" datePattern="yyyy-MM-dd"/>
    <property name="LOG_PATTERN"
              value="[%d{yyyy-MM-dd HH:mm:ss}:%-4relative] %green([%thread]) %highlight(%-5level) %boldWhite([%C.%M:%yellow(%L)]) - %msg%n"/>

    <springProfile name="prod">
        <appender name="FILE-INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>./log/info/info-${BY_DATE}.log</file>
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>INFO</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <encoder>
                <pattern>${LOG_PATTERN}</pattern>
            </encoder>
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>./backup/info/info-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
                <maxFileSize>100MB</maxFileSize>
                <maxHistory>30</maxHistory>
                <totalSizeCap>3GB</totalSizeCap>
            </rollingPolicy>
        </appender>

        <appender name="FILE-WARN" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>./log/warn/warn-${BY_DATE}.log</file>
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>WARN</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <encoder>
                <pattern>${LOG_PATTERN}</pattern>
            </encoder>
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>./backup/warn/warn-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
                <maxFileSize>100MB</maxFileSize>
                <maxHistory>30</maxHistory>
                <totalSizeCap>3GB</totalSizeCap>
            </rollingPolicy>
        </appender>

        <appender name="FILE-ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>./log/error/error-${BY_DATE}.log</file>
            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>ERROR</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
            <encoder>
                <pattern>${LOG_PATTERN}</pattern>
            </encoder>
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>./backup/error/error-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
                <maxFileSize>100MB</maxFileSize>
                <maxHistory>30</maxHistory>
                <totalSizeCap>3GB</totalSizeCap>
            </rollingPolicy>
        </appender>

        <root level="INFO">
            <appender-ref ref="FILE-INFO"/>
            <appender-ref ref="FILE-WARN"/>
            <appender-ref ref="FILE-ERROR"/>
        </root>
    </springProfile>
</configuration>

Post

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

로그(log) 기록하기, SLF4J란?

장장스 — Sat, 29 Jan 2022 20:25:54 +0900

로그(log) 기록하기, SLF4J란?

SLF4J 란?

Simple Logging Facade for Java (SLF4J)

Facade(퍼사드 패턴 : 간략화된 인터페이스를 제공해주는 디자인 패턴)라는 단어의 뜻 처럼 JAVA에서 심플한 로깅 인터페이스를 제공하는 API 입니다.

※ API: (Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)

다양한 로깅 프레임워크(logging framework)들에 대한 추상화 역할을 제공하여 최종 사용자가 배포 시 원하는 로깅 프레임워크를 연결할 수 있도록 합니다

위 그림처럼 사용자는 구체적인 구현체에 직접 접근하지 않습니다. SLF4J에 요청하면 바인딩 된 구현체가 로깅 작업을 하게 됩니다.

SLF4J API를 사용하는 로깅 프레임워크로는 java.util.logging, log4j, logback, log4j2 등이 있습니다.

Spring Boot는 SLF4J와 logback을 기본으로 사용하고 있습니다.

SLF4J 모듈 구성

SLF4J는 크게 3가지 모듈로 구성되어 있습니다.

1. SLF4J-API

Logger interface 를 제공하며 로그 레벨에 따른 출력(printing) 메서드들을 제공합니다.

로그 레벨	출력 메서드	설명
TRACE	trace()	세분화된 정보 이벤트를 지정
DEBUG	debug()	애플리케이션을 디버그하는 데 가장 유용한 세분화된 정보를 지정
INFO	info()	대략적인 수준에서 응용 프로그램의 진행 상황을 강조하는 정보 메시지를 지정
WARN	warn()	잠재적으로 위험이 될 상황을 지정
ERROR	error()	애플리케이션이 계속 실행되도록 허용할 수 있는 오류 이벤트를 지정
FATAL	X	응용 프로그램이 중단될 수 있는 매우 심각한 오류

2. SLF4J Binding (jar)

SLF4J-API 모듈은 class-path에 있는 로깅 프레임워크(logging framework) 구현체를 Class-loader 방식으로 바인딩 합니다. 이 때 구현체는 오직 하나만 있어야 합니다. class path에 jar파일이 없을 시 no-operation 으로 설정됩니다. 즉, 아무것도 출력하지 않습니다.

위 사진은 로깅 프레임 워크를 바인딩하는 방법을 그래프로 표현한 사진입니다.

(아무것도 바인딩 하지 않은 경우)
logback-classic.jar, logback-core.jar (logback-classic)
slf4j-reload4j.jar (reload4j)
slf4j-jdkXX.jar (java.util.logging)
slf4j-simple.jar (simple)
slf4j-nop.jar (no-operation)

3. SLF4J Bridge

프로젝트에서 일부 구성 요소는 SLF4J가 아닌 다른 로깅(logging) API에 의존하는 경우가 있습니다. 예를 들면 spring-context는 JCL(Jarkarta Commons Logging) API를 사용합니다. 또한 이러한 구성 요소가 SLF4J로 전환되지 않을 수도 있습니다. 이러한 상황을 처리하기 위해 SLF4J는 log4j, JCL 및 java.util.logging API에 대한 호출을 리디렉션하여 SLF4J API에 대해 만들어진 것처럼 동작하도록 하는 여러 브리징 모듈과 을 제공합니다.

그림은 SLF4J Bridge 모듈의 동작 아이디어 입니다.

SLF4J 동작 방식

Post

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[스프링 부트] InvalidDataAccessApiUsageException: Unknown entity #그래들 멀티 모듈

장장스 — Fri, 28 Jan 2022 01:31:14 +0900

[스프링 부트] InvalidDataAccessApiUsageException: Unknown entity 에러

#그래들 멀티 모듈

인텔리제이로 프로젝트를 하던 중 에러가 났다.

JPA를 사용하고 있었는데 web, admin 에서 사용되는 domain이 공통으로 겹쳐게 되자 이를 효율적으로 사용하기 위해 web, admin, domain 3개의 멀티 그래들 모듈로 프로젝트를 구성한 상태였다.

├── web
│   ...
│   └── build.gradle
├── admin
│   ...
│   └── build.gradle
├── domain
│   ...
│   └── build.gradle
└── settings.gradle

그리고 admin에서 서버를 실행하자 다음과 같은 에러가 발생했다.

InvalidDataAccessApiUsageException: Unknown entity

domain 모듈을 admin 모듈의 서브 모듈로 설정 했지만 스프링 컨테이너가 domain 모듈에 있는 Entity를 인식하지 못해서 발생한 문제였다.

admin 모듈에서 scanBasePackages을 이용해서 domain 모듈을 scan 하면 스프링 컨테이너가 Entity를 인식할 것이라 생각했는데 되지 않았다.

@SpringBootApplication(scanBasePackages = {"com.admin.*","com.domain.*"})

해결방법

@EntityScan 어노테이션을 사용하면 다른 모듈의 Entity를 스캔할 수 있었다.

@EntityScan("com.domain.*")

또한 repository도 @EnableJpaRepositories 어노테이션을 사용해 스캔 할 수 있었다.

@EnableJpaRepositories("com.domain.*")

최종적인 admin 모듈의 AdminApplication 코드이다.

@SpringBootApplication(scanBasePackages = {"com.admin.*","com.domain.*"})
@EntityScan("com.domain.*")
@EnableJpaRepositories("com.domain.*")
public class AdminApplication {

   public static void main(String[] args) {
      SpringApplication.run(AdminApplication.class, args);
   }

}

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[Spring boot] MySql 연결 에러, com.mysql.cj.jdbc.driver

장장스 — Wed, 19 Jan 2022 00:01:10 +0900

[스프링 부트] MySql 연결 에러,

com.mysql.cj.jdbc.driver

this is deprecated. the new driver class is `com.mysql.cj.jdbc.driver'. the driver is automatically registered via the spi and manual loading of the driver class is generally unnecessary.

뭔데

4.4.1.3 Changes in the Connector/J API

The name of the class that implements java.sql.Driver in MySQL Connector/J has changed from com.mysql.jdbc.Driver to com.mysql.cj.jdbc.Driver. The old class name has been deprecated.

버전 업데이트에 따라 Class 이름이 변경 되었다고 한다.

application.properties 사용

application.properties 을 사용할 경우 아래와 같이 변경한다.

spring.datasource.driver-class-name=com.mysql.jdbc.Driver

spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

application.yml 사용

application.yml 을 사용할 경우 아래와 같이 변경한다.

spring:
  datasource:
    driver-class-name: com.mysql.jdbc.Driver

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver

Post

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[백준] 3197 백조의 호수 #JAVA #BFS #시간초과

장장스 — Thu, 13 Jan 2022 12:10:07 +0900

[백준] 3197 백조의 호수 #JAVA #BFS #시간초과

코드

import java.io.*;
import java.util.*;

public class Main {
	
	static int[] dx = {0,1,0,-1};
	static int[] dy = {1,0,-1,0};
	static int R, C;
	static char[][] map;
	static boolean[][] visSwan, visWater;
	static Queue<int[]> waterQ, waterNextQ, swanQ, swanNextQ;
	
	static int startX, startY, endX, endY;
	
	public static void main(String[] args) throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		
		StringTokenizer st = new StringTokenizer(br.readLine());
		R = Integer.parseInt(st.nextToken()); //y
		C = Integer.parseInt(st.nextToken()); //x
		
		map = new char[R][C];
		
		visSwan = new boolean[R][C];
		swanQ = new LinkedList<>();
		swanNextQ = new LinkedList<int[]>();
		
		visWater = new boolean[R][C];
		waterQ = new LinkedList<int[]>();
		waterNextQ = new LinkedList<int[]>();
		
		int resultDays = -1;
		
		List<int[]> startEnd = new ArrayList<int[]>();
		
		for (int i = 0; i < R; i++) {
			String temp = br.readLine();
			for (int j = 0; j < C; j++) {
				
				if(temp.charAt(j) == 'X') {
					map[i][j] = 'X';
					
				}else {
					if(temp.charAt(j) == 'L') {
						startEnd.add(new int[] {j,i}); //x,y
					}
					waterQ.add(new int[] {j,i}); //x,y
					visWater[i][j] = true;
					map[i][j]='.';
				}
				
			}
		}
		
		startX =  startEnd.get(0)[0];
		startY =  startEnd.get(0)[1];
		endX =  startEnd.get(1)[0];
		endY =  startEnd.get(1)[1];
		
		visSwan[startY][startX] = true;
		swanQ.add(new int[] {startX, startY});

		while (!visSwan[endY][endX]) {
			waterBFS();
			swanBFS();
			resultDays++;
		}
		
		System.out.println(resultDays);
		
	}
	
	private static void swanBFS() {
		
		while (!swanNextQ.isEmpty()) {
			swanQ.add(swanNextQ.poll());
		}
		
		
		while (!swanQ.isEmpty()) {

			int[] cur = swanQ.poll();

			int x = cur[0];
			int y = cur[1];

			for (int k = 0; k < 4; k++) {
				int nx = x + dx[k];
				int ny = y + dy[k];

				if (nx < 0 || ny < 0 || nx >= C || ny >= R)	continue;
				if (visSwan[ny][nx]) continue;

				if (map[ny][nx] == 'X') {
					swanNextQ.add(new int[] {nx, ny});
				} else {
					swanQ.add(new int[] {nx, ny});
				}
				
				visSwan[ny][nx] = true;
			}
		}
	}
	
	private static void waterBFS() {
		while (!waterNextQ.isEmpty()) {
			int[] cur = waterNextQ.poll();
			map[cur[1]][cur[0]] = '.';
			waterQ.add(cur);
		}
		
		while (!waterQ.isEmpty()) {

			int[] cur = waterQ.poll();

			int x = cur[0];
			int y = cur[1];
			
			for (int k = 0; k < 4; k++) {
				int nx = x + dx[k];
				int ny = y + dy[k];

				if (nx < 0 || ny < 0 || nx >= C || ny >= R)	continue;
				if (visWater[ny][nx]) continue;
				
				if (map[ny][nx] == 'X') {
					waterNextQ.add(new int[] {nx, ny});
					visWater[ny][nx] = true;
				}
				
			}
		}
	}
}

풀이

BFS를 통해 빙하를 녹여 물로 만든다.
- 시간 단축을 위해 2개의 큐를 사용한다. waterQ, waterNextQ(다음 턴에 물이 될 좌표)
- waterQ를 BFS하며 다음 턴에 빙하에서 물이 될 좌표를 탐색하여 waterNextQ에 담는다.
- 턴이 지날 때 마다 waterNextQ의 좌표를 waterQ로 옮긴다. 이 때, map을 'X(빙하)'에서 '.(물)'로 변환한다.
BFS를 통해 백조가 만날 수 있는지 확인한다.
- 시간 단축을 위해 2개의 큐를 사용한다. swanQ, swanNextQ(다음 턴에 백조가 갈 수 있는 좌표)
- swanQ를 BFS하며 다음 턴에 백조가 갈 수 있는 좌표를 탐색하여 swanNextQ에 담는다.
다른 백조가 있는 좌표에 방문 가능 할 때까지 1번과 2번을 반복한다.

주의 사항

백조의 좌표는 물이다. 물에 대한 BFS를 돌릴 때 해당 좌표를 큐에 넣어야 한다.

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[백준] 18809 Gaaaaaaaaaarden #JAVA #백트래킹 #bfs

장장스 — Wed, 12 Jan 2022 14:34:14 +0900

[백준] 18809 Gaaaaaaaaaarden #JAVA #백트래킹 #bfs

오랜 시간이 걸려서 풀었던 문제.

코드

import java.io.*;
import java.util.*;

public class Main {

	static List<int[]> baeyang;
	static int N,M,G,R;
	
	static int[][] garden;
	static int[] selectBaeyang;
	static int[] selectGR;
	static boolean[] isUsedBaeyang;
	static int[] spotG, spotR;
	
	static int[] dx = {0,1,0,-1};
	static int[] dy = {1,0,-1,0};
	
	static int max = 0;
	
	public static void main(String[] args) throws IOException{

		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		
		StringTokenizer st = new StringTokenizer(br.readLine());
		
		N = Integer.parseInt(st.nextToken()); //y
		M = Integer.parseInt(st.nextToken()); //x
		G = Integer.parseInt(st.nextToken());
		R = Integer.parseInt(st.nextToken());
		
		
		garden = new int[N][M];

		
		// 0 - 호수, 못들어가는 땅
		// 1 - 배양액, 배양액을 뿌릴 수 없는 땅
		// 2 - 배양액을 뿌릴 수 있는 땅

		
		baeyang = new ArrayList<int[]>();
		
		for (int i = 0; i < N; i++) {
			st = new StringTokenizer(br.readLine());
			for (int j = 0; j < M; j++) {
				garden[i][j] = Integer.parseInt(st.nextToken());
				
				if(garden[i][j] == 2) {
					baeyang.add(new int[] {j,i}); //x,y
				}
			}
			
		}
		
		isUsedBaeyang = new boolean[baeyang.size()];
		spotG = new int[G];
		spotR = new int[R];
		
		Arrays.fill(spotG, -1);
		Arrays.fill(spotR, -1);
		
		findSpotG(0);
		
		System.out.println(max);
	}
	
	/**
	 * G 배양액 좌표를 백트래킹으로 구한다.
	 */
	static void findSpotG(int k) {
		if(k == G) {
			findSpotR(0); // G 배양액 좌표를 다 구하면, R 배양액 좌표를 구한다.
			return;
		}
		
		for (int i = 0; i < baeyang.size(); i++) {
			if(isUsedBaeyang[i]) continue;
			if(k > 0 && spotG[k-1] > i) continue;
			isUsedBaeyang[i] = true;
			spotG[k] = i;
			findSpotG(k+1);
			spotG[k] = -1;
			isUsedBaeyang[i] = false;
			
		}
	}
	
	/**
	 * R 배양액 좌표를 구한다.
	 */
	static void findSpotR(int k) {
		if(k == R) {
			bfs(); //G,R 배양액의 좌표를 가지고 BFS를 통해 꽃의 개수를 구한다.
			return;
		}
		
		for (int i = 0; i < baeyang.size(); i++) {
			if(isUsedBaeyang[i]) continue;
			if(k > 0 && spotR[k-1] > i) continue;
			isUsedBaeyang[i] = true;
			spotR[k] = i;
			findSpotR(k+1);
			spotR[k] = -1;
			isUsedBaeyang[i] = false;
			
		}
	}
	
	static void bfs() {
		int flower = 0;
		int[][] dist = new int[N][M];
		char[][] flw = new char[N][M];
		
		Queue<int[]> Q = new LinkedList<int[]>();
		
		for (int g : spotG) {
			int tmp[] = baeyang.get(g);
			int x = tmp[0];
			int y = tmp[1];
			
			flw[y][x] = 'G';
			dist[y][x] = 1;
			Q.add(new int[] {x,y, 0, 1}); // , G/R ,time;
		}
		
		for (int r : spotR) {
			int tmp[] = baeyang.get(r);
			int x = tmp[0];
			int y = tmp[1];
			
			flw[y][x] = 'R';
			dist[y][x] = 1;
			Q.add(new int[] {x,y, 1, 1});
		}
		
		// 0 - 호수, 못들어가는 땅
		// 1 - 배양액, 배양액을 뿌릴 수 없는 땅
		// 2 - 배양액을 뿌릴 수 있는 땅

			
		//초록 배양액 bfs
		while (!Q.isEmpty()) {
			int[] cur = Q.poll(); //x,y
			int x = cur[0];
			int y = cur[1];
			char color = cur[2] == 0 ? 'G' : 'R'; //G:0 , R:1
			int time = cur[3];
			
			if(flw[y][x] == 'F') continue; //중요! : 이미 큐에 들어온 좌표가 꽃이 되는 경우가 있다.
			
			for (int k = 0; k < 4; k++) {
				int nx = dx[k] + x;
				int ny = dy[k] + y;
				
				if(nx<0 || ny<0 || nx>= M || ny >= N) continue;
				if(garden[ny][nx] == 0) {
					flw[ny][nx] = 'h';
					continue; //호수
				}
				if(flw[ny][nx] == 'F') continue; //이미 꽃이 피었다.
				if(flw[ny][nx] == color) continue; //같은 색상의 배양액
					
				//다른 색상의 배양색을 만날경우
				if(((color == 'G' && flw[ny][nx] == 'R')) || (color == 'R' && flw[ny][nx] == 'G')) {
					if(dist[ny][nx] == time+1) {
						flw[ny][nx] = 'F';
						flower++;
					}
					continue;
				}
				
				flw[ny][nx] = color;
				dist[ny][nx] = time+1;
				
				Q.add(new int[] {nx,ny, cur[2], time+1}); //x,y
			}
		}
		
		max = Math.max(flower, max);
		
		
	}

}

풀이

먼저 배양액이 뿌려질 수 있는 좌표의 조합을 구한다.
- 백트래킹을 사용하여 G의 좌표를 구하고, 다음으로 R의 좌표를 구했다.
좌표를 구한 뒤 BFS를 이용하여 꽃이 피는 개수를 구한다.
- 큐에 {x좌표, y좌표, 배양액컬러, 시간} 을 넣는다. (문제와 다르게 시간은 1부터 시작하는 것으로 했다.)
- 큐에서 꺼낸 현재 좌표가 꽃인지 체크한다.
- 조건에 맞는 좌표를 다시 큐에 삽입한다.
  - 방문 좌표가 호수인지 체크
  - 방문 좌표가 꽃이 피었는지 체크
  - 방문 좌표가 같은 색상의 배양액이 방문했는지 체크
  - 방문 좌표가 다른 생상의 배양액이 방문했는지 체크 -> 방문 시간이 같으면 꽃을 피움

주의 사항

큐에서 꺼낸 현재 좌표가 꽃인지 체크한다.
- 위 조건 때문에 계속 틀렸었다. G가 방문하고 새로운 좌표를 큐에 넣게 된다. 그런데 R이 해당 좌표를 같은 시간에 방문하면 해당 좌표는 꽃이 된다. 즉, 큐에 들어있는 G의 좌표가 이미 꽃인 경우가 발생하게 되는데 이부분을 체크하지 못해서 계속해서 갯수가 정답보다 많이 나오는 오류에 걸렸었다.
- 설계에서 해당 부분을 놓치게 되니, 오류를 찾기 위해 무한 디버그에 빠져버렸다.
- 풀이 계획을 잘 세우자..

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[백준] 1202 보석 도둑 #JAVA #우선순위 큐

장장스 — Sun, 26 Dec 2021 14:34:03 +0900

[백준] 1202 보석 도둑 #JAVA #우선순위 큐

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class Main {

	public static void main(String[] args) throws IOException{
		
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringTokenizer st;
		
		st = new StringTokenizer(br.readLine());
		
		int N = Integer.parseInt(st.nextToken()); //보석 정보 개수
		int K = Integer.parseInt(st.nextToken());
		
		//1. 보석의 무게, 가치를 담는 우선순위 큐 정의
		PriorityQueue<int[]> pQ = new PriorityQueue<int[]>((a,b)->{
			if(a[0]-b[0] == 0) {
				return b[1]-a[1]; //가치 내림차순 정렬
			}
			return a[0]-b[0];//무게 오름 차순 정렬
		});
		
		//1-1. 우선순위 큐에 보석 정보 저장	
		for (int i = 0; i < N; i++) {
			st = new StringTokenizer(br.readLine());
			
			int M = Integer.parseInt(st.nextToken()); //보석 무게
			int V = Integer.parseInt(st.nextToken()); //보석 가격
			
			pQ.add(new int[] {M,V});
			
		}
		
		//2. 가방 정보 저장하는 List
		List<Integer> bag = new ArrayList<Integer>();
		for (int i = 0; i < K; i++) {
			int C = Integer.parseInt(br.readLine()); //가방 최대 무게 
			bag.add(C);
		}
		//2-1. 가방 오름차순 정렬
		Collections.sort(bag);
		
		
		//3. 가방에 들어갈 수 있는 무게를 valueQ로 옮긴후 가장 가치가 큰 값을 total에 더한다.
		PriorityQueue<Integer> valueQ = new PriorityQueue<Integer>(Collections.reverseOrder());
		long total = 0;
		for (int i = 0; i < bag.size(); i++) {
			int weight = bag.get(i);
			
			while (!pQ.isEmpty()) {
				 
				if(pQ.peek()[0] <= weight) {
					valueQ.add(pQ.poll()[1]); //가치만 넣는다.
				}else {
					break;
				}
			}
			
			if(valueQ.isEmpty()) continue;
			total += valueQ.poll();
			
			
		}

		
		System.out.println(total);
		
		
	}

}

풀이

그리디 알고리즘기반으로 무게와 가치를 고려해야 하다보니 꽤 복잡하여 고생한 고전한 문제입니다.

제한 시간이 1초로 시간초과와의 싸움이였습니다.(넘나 싫은 것,,)

실패한 방법은,

1. TreeMap을 사용하여 <Integer(가치), 우선 순위 큐> 를 사용하여 보석의 정보를 저장합니다.

2. 가장 가치가 큰 값을 담을 가장 작은 가방 탐색을 실시합니다.

2-1. 가방을 정렬 후 이분탐색을 실시하여 under bound 값을 찾기

결과는 시간 초과 였습니다.(~~logN x logN + logN 맞나?~~)

다른 방법을 찾아 시도 하여 성공하였습니다.

1. 우선순위 큐에 보석 정보를 담습니다. <int[]>

1-1. [0]번 인덱스는 M(무게) [1]번 인덱스는 V(가치)가 담기도록 합니다.

1-2. 무게는 오름 차순으로 정렬되고, 가치는 내림차순으로 정렬되게 합니다. (가볍고, 비싼거 먼저!)

2. 가방 정보를 List에 담습니다. (정리하며 생각해보니 배열도 됩니다 헤헤)

2-1. 가방을 오름차순으로 정렬합니다. (2, 5, 10, ··· )

3. 가장 작은 가방부터 순회하며 가장 높은 가치의 물건을 담도록 합니다.

3-1. 새로운 우선순위 큐 <Integer>를 생성한다.

3-2. 인자는 V(가치)가 내림차순으로 정렬되게 한다.

3-3. 가장 작은 가방에 들어갈 수 있는 가장 큰 가치의 보석을 하나씩 담는다.

※참고: 우선순위 큐의 시간복잡도 IN 자바

시간 복잡도	메서드
O(log(n))	offer, poll, remove, add
O(n)	remove
O(1)	peek, element, size

주의 사항

total 변수는 long이여야 합니다. 가방 300,000개가 보석 가치 1,000,000을 담게 되면 int의 범위를 초과하게 됩니다.

반례

INPUT 1

3 2
5 20
7 25
8 50
5
5

OUTPUT 1

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[백준] 7662 이중 우선순위 큐 #JAVA #이진 탐색 트리

장장스 — Fri, 24 Dec 2021 18:15:57 +0900

[백준] 7662 이중 우선순위 큐 #JAVA #이진 탐색 트리

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Map.Entry;
import java.util.StringTokenizer;
import java.util.TreeMap;

public class Main {

	public static void main(String[] args) throws IOException {

		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringBuilder sb = new StringBuilder();
		StringTokenizer st;

		int T = Integer.parseInt(br.readLine());
		
		for (int t = 0; t < T; t++) {
			int k = Integer.parseInt(br.readLine());

			TreeMap<Integer, Integer> tree = new TreeMap<>();

			for (int i = 0; i < k; i++) {
				st = new StringTokenizer(br.readLine());

				String cmd = st.nextToken();
				int number = Integer.parseInt(st.nextToken());

				if (cmd.equals("I")) {
					if(tree.get(number) != null) {
						tree.put(number, tree.get(number)+1);
					}else {
						tree.put(number, 1);
					}
					
				} else if (cmd.equals("D")) {
					if (tree.isEmpty())	continue;

					if (number == 1) { // 최댓값 삭제
						Entry<Integer, Integer> entry = tree.pollLastEntry();
						if(entry.getValue() > 1) {
							tree.put(entry.getKey(), entry.getValue()-1);
						}
						
					} else if (number == -1) { // 최솟값 삭제
						Entry<Integer, Integer> entry = tree.pollFirstEntry();
						if(entry.getValue() > 1) {
							tree.put(entry.getKey(), entry.getValue()-1);
						}
					}
				}

			}
			if (tree.isEmpty()) {
				sb.append("EMPTY");
			} else {
				int max = tree.lastKey();
				int min = tree.firstKey();
				sb.append(max + " " + min);
			}
			sb.append("\n");
		}
		System.out.println(sb.toString());

	}

}

풀이

문제 제목처럼 이중 우선순위 큐라는 자료구조가 있는 줄 알았다. 그런 자료구조는 자바에 존재하지 않았다.(~~다른 언어는 있을지도?~~)

그래서 일단 우선순위 큐를 이용해서 풀었다. 하나의 우선순위 큐를 두고 삭제 시 최소인 경우 poll() 메서드를 사용해서 삭제했고, 최대인 경우는 loop문을 통해 마지막 원소를 찾아 삭제 하려고 했다(loop문을 짜는 순간 시간 초과임을 알았다.)

시간 초과를 해결하기 위해 삭제의 시간복잡도가 O(lonN)인 트리 자료구조를 사용하여 해결하였다.

자바에서는 TreeSet 과 TreeMap 두 가지가 있다. 모두 이진 탐색 트리다.

해당 문제에서는 중복된 수가 입력이 될 수 있으므로 TreeSet을 사용하지 않고 TreeMap을 사용하였다.

주의 사항

같은 수가 입력이 될 수 있다. TreeMap을 사용하여 구현하며 중복된 입력시 <key, value>에서 value의 값이 증가하도록 구현한다.
삭제 시 value의 값이 1보다 큰 경우 삭제가 아니라, value 값을 -1 한다.

반례

INPUT

1
3
I 100
I 100
D 1

OUTPUT

100 100

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[GoF]스테이트 패턴(State Pattern)

장장스 — Mon, 20 Dec 2021 21:12:41 +0900

스테이트 패턴(State Pattern)

스테이트 패턴이란?

클래스가 하나의 상태(state)에 따라 내부의 메서드의 기능이 바뀌는 경우(같은 기능에서 분기(if-else)발생)한다고 하면 이를 각각의 클래스로 분리하는 패턴이다.

스테이트 패턴 왜 사용할까?

객체의 기능이 어떤 상태에 있느냐에 따라 달라질 수 있는데(ex 자동차의 에코모드, 스포츠모드) 이러한 상태가 여러가지이면 if-else와 같은 분기로 표현이 되어 수정,삭제, 추가시 단점이 발생 할 수 있다. 이 때, 기능이 상태(특정 변수같은)에 의존적이라면 스테이트 패턴을 사용하여 클래스로 표현하는 것이 적절하다.

스테이트 패턴을 사용하게 되면

상태에 따라 기능을 분리하여 구현
새로운 상태 추가나 삭제가 용이함

클래스 다이어그램

객체 협력

Context : ConcreteState의 인스턴스를 관리하고 서로 상태가 바뀌는 구간을 구현다
State : Context 가 사용할 메서드를 선언한다. (~~추상 클래스or인터페이스 둘다 되겠지~~)
ConcreateState : 각 상태 클래스가 수행할 State에 선언된 메서드를 구현한다.

코드보기 Click!

GIT COMMIT 링크 열기!

[GoF] 어댑터패턴(Adapter Pattern)

장장스 — Sun, 19 Dec 2021 21:21:06 +0900

어댑터 패턴(Adapter Pattern)

어댑터 패턴이란?

서로 다른 인터페이스를 중간에서 연결해주기 위해 사용하는 패턴입니다. 이미 사용중이거나 정의된 인터페이스들을 중간에서 맞춰서 적용해 줄 수 있습니다.

어댑터 패턴 왜 사용할까?

클라이언트에서 사용하던 방식대로 호출하여 사용할 수 있도록 조정이 가능합니다. 서로 일치하지 않는 인터페이스를 변경하지 않고 중간에서 호출하여 사용할 수 있도록 제공합니다. 일종의 wrapper와 유사합니다.

어댑터 패턴을 사용하게 되면

Adpter 패턴을 사용하여 클라이언트가 사용하는 방식은 동일하면서 여러 기능이 제공될 수 있다.

클래스 다이어그램

1) 객체 어댑터 (상속)

2) 클래스 어댑터 (합성)

객체 협력

Target : 클라이언트가 사용할 인터페이스를 정의
Client : Target 인터페이스를 사용하는 객체
Adaptee : 실제 적용될 기능이 제공되는 클래스
Adapter : Target 인터페이스에 Adaptee의 인터페이스를 맞추는 클래스

코드보기 Click!

GIT COMMIT 링크 열기!

[GoF]컴포지트 패턴(Composite Pattern)

장장스 — Sat, 18 Dec 2021 19:09:41 +0900

컴포지트 패턴(Composite Pattern)

컴포지트 패턴이란?

그릇과 내용물을 동일시 하는 패턴으로 하나 이상의 유사한 객체를 구성으로 설계된 객체로 모두 유사한 기능을 나타낸다.

컴포지트 패턴 왜 사용할까?

부분과 전체에 대한 복합 객체의 트리구조를 나타낼 수가 있습니다.

클라이언트가 개별 객체와 복합 객체를 동일하게 다룰 수 있는 인터페이스를 제공합니다.

재귀적인 구조입니다.

컴포지트 패턴을 사용하게 되면

기본 객체는 복합 객체에 포함이 되고, 복합 객체 역시 또 다른 복합 객체에 포함될 수 있다.
클라이언트 코드는 기본객체와 복합객체에 대한 일관된 프로그래밍을 할 수 있다.
기본 객체가 증가하여도 전체 객체의 코드에 영향을 주지 않는다.
새로운 요소의 추가가 편리하고 범용성 있는 설계가 가능하다.

클래스 다이어그램

객체 협력

Component
- 전체와 부분 객체에서 공통으로 사용할 기능 구현
- 전체 클래스가 부분요소들을 관리하기 위해 필요한 인터페이스 선언
- 전체와 부분 객체에서 공통적으로 사용할 인터페이스 선언
Leaf
- 집합 관계에서 다른 객체를 포함할 수는 없고 포함되기만 하는 객체로 가장 기본이 되는 기능을 구현
Composite
- 포함한 여러 객체를 저장하고 관리하는 기능을 구현
- 여러 객체를 포함하는 복합 객체에 대한 기능 구현
Client
- Component에 선언된 인터페이스를 통하여 부분과 전체를 동일하게 처리

코드보기 Click!

GIT COMMIT 링크 열기!

[백준] 3190 뱀 #JAVA #시뮬레이션

장장스 — Fri, 17 Dec 2021 13:33:42 +0900

[백준] 3190 뱀 #JAVA #시뮬레이션

코드

import java.io.*;
import java.util.*;
public class Main {

	public static void main(String[] args) throws IOException{

		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		
		int N = Integer.parseInt(br.readLine());//보드 크기
		int K = Integer.parseInt(br.readLine());//사과 개수
		
		int[][] board = new int[N][N];
		
		StringTokenizer st;
		
		for (int i = 0; i < K; i++) { //사과 자리
			st = new StringTokenizer(br.readLine());
			int y = Integer.parseInt(st.nextToken());
			int x = Integer.parseInt(st.nextToken());
			
			board[y-1][x-1] = 1;
			
		}
		
		Deque<int[]> snake = new LinkedList<>();
		snake.addFirst(new int[] {0,0});
		int snakeHead = 0; //0동 1남 2서 3북
		
		int L = Integer.parseInt(br.readLine());//방향 전환
		int[] dir = new int[10001];
		
		for (int i = 0; i < L; i++) {
			st = new StringTokenizer(br.readLine());
			int sec = Integer.parseInt(st.nextToken());
			String d = st.nextToken();
			
			if(d.equals("L")) dir[sec] = -1;
			else if(d.equals("D")) dir[sec] = 1;
			
		}
		
		int second = 0;
		while (true) {
			second++;
			
			int[] head =snake.peekFirst();
			
			int ny = head[0];
			int nx = head[1];
			if(snakeHead == 0) {//동
				nx += 1;
			} else if(snakeHead == 1) {//남
				ny += 1;
			} else if(snakeHead == 2) {//서
				nx -= 1; 
			} else if(snakeHead == 3) {//북
				ny -= 1;
			}
			
			//벽 부딪힘 check
			if(nx<0 || ny<0 || nx >=N || ny>=N) break;
			
			//몸통 부딪힘 check
			Iterator<int[]> iter= snake.iterator();
			boolean isBody = false;
			while (iter.hasNext()) {
				int[] tmp = iter.next();
				if(ny == tmp[0] && nx == tmp[1]) {
					isBody = true;
					break;
				}
			}
			if(isBody)break;
			

			snake.addFirst(new int[] {ny,nx});//머리 이동
			if(board[ny][nx] == 1) {
				board[ny][nx] = 0; //사과 삭제
			}else {
				snake.removeLast();//사과 안먹었으면 꼬리 이동
			}			
			
			if(dir[second] != 0) {
				snakeHead += dir[second];
				if(snakeHead<0) snakeHead += 4;
				snakeHead %= 4;
			}
			
		}
		
		System.out.println(second);
	}

}

풀이

Dequeue에 뱀의 좌표를 머리 ~ 꼬리 순으로 넣는다.
뱀의 머리가 4방향중 어디인지 정의한다.
이동할 떄마다 배열 범위를 벗어나는지 체크하고, 뱀 몸통에 부딪히는지 체크한다.
뱀이 사과를 먹으면 몸이 길어지고, 사과는 삭제한다.

주의 사항

뱀의 머리가 범위를 벗어나는 것을 체크해야 한다. (0~3 범위)
뱀이 사과를 먹고나서 사과를 삭제해야한다.

반례

아래 반례가 되지 않는다면 사과처리에 대해 다시 확인해 본다.

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[GoF]데코레이터 패턴(Decorator Pattern)

장장스 — Thu, 16 Dec 2021 22:38:08 +0900

데코레이터 패턴(Decorator Pattern)

데코레이터 패턴이란?

데코레이터 패턴은 장식과 실제 내용물을 동일시 하는 패턴으로 생성된 객체에 동적으로 행위를 추가하는 패턴입니다.

※자바의 I/O 스트림 클래스는 Decorator 패턴을 사용한 것입니다.

Socket socket = new Socket();
BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream()));

데코레이터 패턴 왜 사용할까?

기능을 확장할 때 IS-A 관계라면 상속을 사용하게 됩니다. 그러나 HAS-A 관계라면 상속을 사용하기 모호한 상황이게 됩니다. 무언가 기능을 유연하게 추가하고자 할때 데코레이터 패턴을 사용하여 기능을 확장할 수 있습니다. 즉, 전체 객체를 바꾸는 게 아니라 객체에 새로운 기능을 하나씩 추가할 수 있습니다.

데코레이터 패턴을 사용하게 되면

상속보다 설계의 유연성을 증가시킴
Decorator 조합을 통해 새로운 서비스를 지속적으로 추가 할 수 있음
불필요한 경우 Decorator 삭제가 가능함
Decorator와 실제 컴포넌트는 동일한 것이 아님
작은 규모의 객체들이 많이 생성될 수 있음

클래스 다이어그램

객체 협력

Component : 동적으로 추가할 서비스를 가질 수 있는 객체 정의
ConcreteComponent : 추가적인 서비스가 필요한 실제 객체
Decorator : Component의 참조자를 관리하면서 Component에 정의된 인터페이스를 만족하도록 정의
ConcreteDecorator : 새롭게 추가되는 서비스를 실제 구현한 클래스로 addBehavior()를 구현

코드보기 Click!

GIT COMMIT 링크 열기!

[GoF]브릿지 패턴(Bridge Pattern)

장장스 — Mon, 13 Dec 2021 19:28:10 +0900

브릿지 패턴(Bridge Pattern)

브릿지 패턴이란?

기능의 계층과 구현의 계층을 분리하는 패턴입니다. 추상화와 구현을 분리하여 각각을 독립적으로 변경할 수 있게 합니다. 두 계층을 연결하는 다리(Bridge)를 통해 연결됩니다.

브릿지 패턴 왜 사용할까?

기능의 확장과 구현의 확장을 따로 계층화 하는 것이 목적입니다. 따라서 기능에 대한 여러가지 구현을 다양하게 적용할 수 있습니다. 기능과 구현이 혼재하면 상속의 관계가 복잡하게 섞이게 됩니다.

브릿지 패턴을 사용하게 되면

기능과 구현의 결합도가 약하기 떄문에 기능이 구현 방식에 얽매이지 않는다.
기능의 구현 클래스를 런타임 때 지정이 가능합니다.
구현이 변경되더라도 기능 클래스 부분에 대한 컴파일은 필요 없습니다.
기능과 구현은 독립적으로 확장되며, 클라이언트는 기능의 인터페이스를 사용하므로 구체적인 구현 내용은 숨길 수가 있습니다.

클래스 다이어그램

객체 협력

Abstraction : 추상화 개념의 상위 클래스이고 객체 구현자(Implemntor)에 대한 참조자를 관리
RefinedAbstraction : 추상화 개념의 확장된 기능을 정의
Implementor : Abstraction에 대한 선언을 제공하며, 하위 클래스가 구현해야 하는 기능들을 선언한다
ConcreteImplementor : Implementor에 선언된 기능을 구현합니다. 여러가지 방식이 나올 수 있습니다.

코드보기 Click!

GIT COMMIT 링크 열기!

인텔리제이에 spring-boot-devtools 추가하기

장장스 — Sat, 11 Dec 2021 01:58:30 +0900

인텔리제이에 spring-boot-devtools 추가하기

안녕하세요? 장장스입니다.

intellij에서 spring-boot-devtools를 추가하는 방법입니다.

spring-boot-devtools

STEP_1 build.gradle 파일에 spring-boot-devtools 의존성을 추가합니다.

runtimeOnly('org.springframework.boot:spring-boot-devtools')

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	runtimeOnly('org.springframework.boot:spring-boot-devtools')
}

STEP_2 File -> settings 에서 Compiler를 검색합니다. Build project automatically 옵션을 활성화 합니다.

STEP_3 File -> settings 에서 Advanced Settings를 검색합니다. Allow auto-make to start even if developed application is currently running 옵션을 활성화 합니다.

※ 최신 인텔리제이는 Regisrty에서 compiler.automake.allow.when.app.running 설정이 검색되지 않습니다.

다른 방법도 있어요! 수동으로 리컴파일(Recompile)

STEP2, 3 을 하지 않아도 수동으로 빌드 할 수 있습니다.

html 파일을 수정한 후 Build탭을 확인해 보면 아래 사진과 같이 해당 파일의 Recompile이 활성화 됩니다.

클릭하고 확인하면 정상적으로 반영이 됨을 확인 할 수 있습니다.

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[GoF]전략 패턴(Strategy)

장장스 — Fri, 10 Dec 2021 16:38:18 +0900

전략 패턴(Strategy)

전략 패턴이란?

상황에 따라 전략이나 알고리즘을 교체하여 사용하는 패턴이다.

전략 왜 사용할까?

다양한 알고리즘(혹은 기능)이 존재할 때, 하나의 클래스로 캡슐화 하여 대체가 가능하도록 할 수 있습니다. 새로운 전략을 반영하거나 기존 전략을 삭제할 때 독립적으로 수행되기에 서로 영향을 끼치지 않습니다. 예를 들어 if-else로 같은 내용이 반복적으로 사용되는 경우 전략 패턴 사용을 고려할 수 있습니다.

전략 패턴을 사용하게 되면

인터페이스에 선언된 기능을 구현한 다양한 정책을 다른 클래스에 영향을 주지 않고 추가, 삭제 할 수 있다.
if-else 조건문을 구현하는 것이 아닌 전략 패턴을 사용하여 클래스를 선택하도록 구현하여 유지보수가 용이해진다.

클래스 다이어그램

객체 협력

Strategy :정책이 수행해야 하는 기능들을 인터페이스로 선언
ConcreteStrategy : Strategy에 선언된 여러 기능들을 구현한다. 각 클래스 별로 다른 전략이 구현될 수 있다.
Context : 어떤 ConcreteStrategy 가 수행 될 것인지에 따라 정책을 선택후 Strategy에 선언된 메서드를 사용해 접근한다

코드보기 Click!

GIT COMMIT 링크 열기!

[OS] 스레싱(thrashing)

장장스 — Wed, 8 Dec 2021 10:02:11 +0900

스레싱(thrashing)

안녕하세요? 장장스입니다.

프로세스가 원활하게 수행되기 위해서는 일정 수준 이상의 페이지 프레임을 물리적 메모리에 할당 받아야 합니다. 프로세스가 동작하는데 필요한 최소한의 페이지 프레임을 받지 못한다면 성능에 문제가 발생할 수 있습니다.

스레싱(thrashing)

프로세스가 집중적으로 사용하는 페이지들의 집합이 메모리에 한꺼번에 적재되지 못하여 페이지 부재율(page fault)가 많이 발생하게 되고 CPU 이용율이 급격히 떨어지는 현상을 스레싱이라고 합니다.

CPU 이용율이 낮다는 것은 메모리에 올라와 있는 프로세스의 수가 너무 적어 프로세스가 모두 I/O작업을 함으로써 준비 큐가 비는 경우가 발생했다는 것입니다. 따라서 CPU 이용율이 낮으면 운영체제는 메모리에 올라가는 프로세스의 수를 늘리게 됩니다. 우리는 메모리에 동시에 올라가 있는 프로세스의 수를 다중 프로그래밍의 정도(MPD: Multi-Programming Degree) 라고 부릅니다.

스레싱은 어떻게 발생하는 걸까?

운영체제는 CPU 이용률이 낮으면 MPD를 높입니다. 그러나 과도하게 MPD가 높아지면 프로세스에게 할당되는 메모리의 양이 감소하게 될 것입니다. 프로세스가 원활하게 수행하려면 필요한 최소한의 페이지 프레임들이 있습니다. 그러면 각 프로세스는 수행에 필요한 최소한의 페이지 프레임도 할당 받지 못하게 되어 페이지 부재가 빈번히 발생하게 될 것입니다. 페이지 부재가 발생하면 스왑 영역에서 해당 페이지를 메모리로 가져오기 위해 디스크 I/O 작업이 발생하고 문맥 교환을 통해 다른 프로세스에게 CPU가 이양 됩니다.

이 때 다른 프로세스 역시 할당 받은 메모리 양이 지나치게 적으면 페이지 부재가 발생할 수밖에 없게 됩니다. 그러면 또 다른 프로세스에게 CPU가 할당된다. 결국에는 준비 큐에 있는 모든 프로세스에게 CPU가 한 차례씩 할당되었는데도 모든 프로세스가 다 페이지 부재를 발생시켜 시스템은 페이지 부재를 처리하느라 매우 분주해지고 CPU 이용률은 급격히 떨어지게 된다. 이 상황에서 운영체제는 메모리에 올라와 있는 프로세스의 수가 적어 이러한 현상이 발생했다고 판단하고, MPD를 높이기 위해 또 다른 프로세스를 메모리에 추가하게 된다. 이로 인해 프로세스당 할당된 프레임의 수가 더욱 감소하고 페이지 부재는 더욱 빈번히 발생하게 된다. 이 경우 프로세스들은 서로의 페이지를 교체하며 스왑 인(swap in)과 스왑 아웃(swap out)을 지속적으로 발생시키고, CPU는 대부분의 시간에 일을 하지 않게 됩니다.

스레싱 발생 방지 알고리즘

MPD를 적절히 조절하여 CPU 이용률을 높이면서 스레싱이 발생하는 것을 막는 방법으로 워킹셋 알고리즘과 페이지 부재 빈도 알고리즘이 있습니다.

워킹셋 알고리즘

프로세스가 일정 시간 동안 집중적으로 특정 주소 영역을 참조하는 경향이 있는데 이를 지역성 집합이라고 합니. 워킹셋 알고리즘은 지역성 집합이 메모리에 동시에 올라갈 수 있도록 보장하는 메모리 관리 알고리즘입니다.

워킹셋은 한꺼번에 메모리에 올라가야 하는 페이지들의 집합입니다. 워킹셋 알고리즘은 프로세스의 워킹셋을 구성하는 페이지들이 한꺼번에 올라갈 수 있을 메모리 공간이 있을 때만 동작합니다. 그렇지 않으면 기존 메모리에 존재하는 페이지를 디스크로 스왑 아웃 시켜 공간을 확보합니다. 이러한 방법으로 MPD를 조절하고 스레싱을 방지하게 됩니다.

워킹셋 알고리즘에서 한꺼번에 메모리에 올라가야 할 페이지들의 집합을 결정하기 위해 워킹셋 윈도우를 사용합니다. 윈도우의 크기를 Δ라고 합니다, 워킹셋 알고리즘은 시각 t에서 Δ이전에 참조된 [Δ-t, t] 사이에 참조된 페이지들의 집합으로 결정한다.

워킹셋 윈도우의 크기를 조절하여 워킹셋의 크기를 조절하는 방법으로 프로세스가 메모리를 필요로 할때는 많이 할당하고 적게 필요로 할 때에는 적게 할당하는 동적인 프레임 할당 기능을 수행하게 됩니다.

페이지 부재 빈도 알고리즘

프로세스의 페이지 부재율을 주기적으로 조사하고 이 값에 근거해서 각 프로세스에 할당할 메모리 양을 동적으로 조절하는 알고리즘입니다. 시스템이 미리 정해 놓은 상한값(upper bound)을 넘어가거나 하한값(lower bound)이하로 떨어지게 되면 운영체제가 메모리에 올라가 있는 프로세스의 수를 조절하게 됩니다.

Post

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 페이지 교체 알고리즘 (FIFO, LRU, LFU, NRU, NUR)

장장스 — Tue, 7 Dec 2021 10:15:36 +0900

페이지 교체 알고리즘 (FIFO, LRU, LFU, NRU, NUR)

안녕하세요? 장장스입니다.

가상 메모리 기법을 구현하는 방식 중 하나인 요구 페이징 방식은 페이지 부재가 발생하게 됩니다. 페이지를 교체하는 작업은 오버헤드를 동반하므로 가능하면 페이지 교체가 적게 일어나도록 하는 것이 좋습니다. 페이지 교체가 무엇인지,

페이지 교체

페이지 부재(page fault)가 발생하면 요청된 페이지를 디스크에서 메모리로 읽어와야 합니다. 이때 물리적 메모리에 빈 프레임이 존재하지 않을 수 있습니다. 이 경우 물리적 메모리에 올라와 있는 페이지 중 하나를 선택해서 디스크의 스왑 영역으로 보내야 합니다. 이와 같은 과정을 페이지 교체라고 합니다.

페이지 교체 알고리즘

어떠한 프레임에 있는 페이지를 디스크의 스왑 영역으로 보낼 것인지를 결정하는 알고리즘을 교체 알고리즘이라고 합니다. 이 알고리즘의 목표는 페이지 부재율을 최소화 하는 것입니다. 그러므로 가까운 미래에 참조될 가능성이 가장 적은 페이지를 선택해서 내보내는 것이 성능을 향상 시킬 수 있는 방안이 될 것입니다.

선입선출 알고리즘(FIrst In First Out: FIFO)

페이지 교체 시 물리적 메모리에 가장 먼저 올라온 페이지를 우선적으로 내보내는 알고리즘입니다. 페이지의 향후 참조 가능성을 고려하지 않기 때문에 비효율적인 상황이 발생할 수 있습니다.

아래 그림은 3개의 페이지 프레임을 가질 경우 9번의 페이지 부재와 3번의 페이지 히트가 발생했습니다.

이번엔 페이지 프레임을 4개로 증가 시켰을 때의 과정입니다.

10번의 페이지 부재와 2번의 페이지 히트가 발생했습니다.

분명 페이지 프레임을 더 많이 사용하는데 오히려 페이지 부재 횟수가 증가하는 이상현상이 나타났습니다.

선입선출 알고리즘에서 메모리를 증가해도 페이지 부재가 더 증가하는 FIFO의 이상 현상(FIFO abnomaly)이 발생할 수 있습니다.

LRU 알고리즘 (Least Recently Used Algorithm)

페이지 교체 알고리즘의 성능 향상을 위해선 앞으로 사용 가능성이 낮은 페이지를 우선적으로 내보내는 것이 좋다. 이와 관련해서 시간 지역성이라는 성질이 있다. 시간 지역성은 최근에 참조된 페이지가 미래에 다시 참조될 가능성이 높은 성질을 말한다. LRU 알고리즘은 이와 같은 성질을 활용해서 페이지 교체 시 가장 오래전에 참조가 이루어진 페이지를 내보낸다.

LRU 알고리즘을 사용하니 8번의 페이지 부재와 4번의 페이지 히트가 발생했습니다. FIFO 알고리즘에 비해 페이지 부재 횟수가 감소 했음을 알 수 있습니다.

LFU 알고리즘 (Least Frequently Used Algorithm)

물리적 메모리 내에 존재하는 페이지 중에서 과거에 참조 횟수가 가장 적은 페이지를 교체 시킬 페이지로 결정하는 알고리즘입니다. LFU 알고리즘은 크게 2가지로 나뉘어집니다.

Incache-LFU: 메모리에 적재될 때부터 페이지의 횟수를 카운트 하는 방식
Perfect-LFU: 메모리 적재 여부와 상관 없이 페이지의 과거 총 참조 횟수를 카운트 하는 방식

(Perfect-LFU의 경우 정확하게 참조 횟수를 참조할 수 있지만 시간에 따른 참조의 변화를 반영하지 못하고, 구현이 복잡하다는 단점이 있습니다.)

11번째로 5번을 참조 하려고 하면 페이지 폴트가 발생합니다. 이 때 LRU 알고리즘은 1번 페이지 프레임을 교체하게 됩니다. 이에 반해 LFU 알고리즘은 참조 횟수가 가장 적은 4번 페이지 프레임을 교체하게 됩니다.

1번 페이지가 오랫동안 쓰이지 않았지만 LFU 알고리즘은 참조 횟수가 가장 적은 4번 페이지를 교체 했습니다. 그러나 앞으로 4번 페이지가 계속 사용되는 페이지 일 수도 있습니다. 이처럼, LFU는 최신 흐름을 잘 반영하지 못할 수도 있습니다.

클럭 알고리즘 (NRU or NUR)

클럭 알고리즘은 하드웨어적인 자원을 통해 기존(LRU, LFU)알고리즘의 소프트웨어적인 운영 오버헤드를 줄인 방식입니다. NRU(Not Used Recently) 또는 NUR(Not Recently Used) 알고리즘이라고도 부르기도 합니다.

클럭 알고리즘은 LRU처럼 가장 최근에 참조되지 않은 페이지를 대상으로 선정한다는 점에서 LRU와 근사하지만 교체되는 페이지의 참조 시점이 가장 오래되었다는 것을 보장하지는 않는다.

클럭 알고리즘은 그림처럼 참조 비트(reference bit)를 순차적으로 조사하며 동작합니다.

1. 프레임 내의 페이지가 참조될 때 하드웨어에 의해 1로 자동 세팅됩니다.

2. 클럭 알고리즘은 한 바퀴 돌며 참조되지 않은 페이지의 참조 비트 값을 0으로 바꾼 후 지나갑니다.

3. 참조 비트가 0인 페이지를 방문하면 해당 페이지를 교체합니다.

즉, 페이지가 참조되어 1이 되고, 한 바퀴 도는 동안 사용되지 않으면 0이 되고 다시 한 바퀴를 도는 동안 사용되지 않는 페이지는 참조되지 않았으므로 교체 대상 페이지로 선정하는 알고리즘입니다.

클럭 알고리즘은 시계 바늘이 한 바퀴 도는 동안 걸리는 시간만큼 페이지를 메모리에 유지시켜 페이지 부재율을 줄이도록 설계 되었다. 때문에 클럭 알고리즘을 2차 기회 알고리즘이라 부르기도 한다.

Post

2021.12.06 - [OS] - [OS] 요구 페이징(가상메모리)

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 요구 페이징(가상메모리)

장장스 — Mon, 6 Dec 2021 09:53:20 +0900

요구 페이징(가상메모리)

안녕하세요? 장장스입니다.

우리가 일반적으로 사용하는 컴퓨터의 메모리는 8GB, 16GB로 그 크기가 한정되어 있습니다. 그럼에도 우리는 많은 프로그램을 동시에 띄워 사용하고 있습니다. 운영체제는 한정된 메모리 공간을 효율적으로 사용하기 위해 가상메모리 기법을 사용합니다.

가상메모리 기법은 크게 요구 페이징 방식(demand paging)과 요구 세그먼테이션 방식(demand segmentation)으로 구현이 됩니다. 요구 세그먼테이션 방식의 경우에는 페이지드 세그먼테이션 기법을 사용하는 경우입니다. 대부분의 경우에는 요구 페이징 방식을 사용합니다.

요구 페이징(demand paging)

요구 페이징은 프로그램 실행 시 프로세스를 구성하는 모든 페이지를 한꺼번에 메모리에 올리는 것이 아니라 당장 사용될 페이지만을 올리는 방식입니다. 따라서 요구 페이징 기법에서는 특정 페이지에 대해 CPU의 요청이 들어온 뒤 해당 페이지를 메모리에 적재합니다.

요구 페이징을 사용함으로써 얻을 수 있는 장점은 다음과 같습니다.

1. 필요한 페이지만 메모리에 적재하기 때문에 메모리 사용량이 감소한다.

2. 프로세스 전체를 메모리에 올리는 데 소요되는 입출력 오버헤드가 감소한다.

3. 사용되지 않는 주소 영역에 대한 입출력이 줄어 응답시간이 줄어든다.

4. 시스템이 더 많은 프로세스를 수용할 수 있게 해준다.

5. 물리적 메모리의 제약을 벗어날 수 있다.

페이지 부재(page fault)

가상메모리 기법은 일부 페이지만 메모리에 적재되어 있고 나머지는 디스크의 스왑 영역에 존재합니다. 이러한 이유로 메모리에 페이지가 존재하는지 구별하기 위해 유효-무표 비트(valid-invalid bit)를 두어 각 페이지가 존재하는지 표시합니다.

이때, 페이지가 메모리에 적재되지 않아 유효-무효 비트에 무효로 세팅되어 있는 경우를 페이지 부재(page fault)가 일어났다고 합니다.

요구 페이징의 페이지 부재 처리는 어떻게?

CPU가 무효 페이지에 접근하면 주소 변환을 담담하는 하드웨어인 MMU(Memory Management Unit)가 페이지 부재 트랩을 발생시킵니다. 다음으로 CPU의 제어권이 커널모드로 변경되고 운영체제의 페이지 부재 처리 루틴이 호출됩니다.

1. 운영체제가 해당 페이지에 대한 접근하기 위해 주소가 유효한지 확인합니다.

2. 범위를 벗어나는 영역에 속한 페이지 접근이나 접근 권한 위반을 할 경우 프로세스를 종료시킵니다.

3. 접근이 가능한 경우 물리적 메모리에 비어 있는 프레임을 할당받습니다.

4. 비어 있는 프레임이 없다면 기존에 메모리에 올라와 있는 페이지 중 하나를 디스크로 내보냅니다. (스왑 아웃)

5. 디스크로부터 메모리 적재는 오랜 시간이 걸립니다. 따라서 페이지 부재가 발생한 프로세스는 CPU를 반납하고 PCB에 현재상태를 저장 후 봉쇄 상태가 됩니다.

6. 디스크 입출력이 완료되어 인터럽트가 발생하면, 해당 페이지의 유효-무효 비트를 유효로 수정합니다.

7. 봉쇄되었던 프로세스를 준비 큐로 이동시킵니다.

8. CPU를 할당 받고 PCB로부터 저장한 값을 복원시켜 중단되었던 명령부터 실행을 이어갑니다.

Post

2021.12.07 - [OS] - [OS] 페이지 교체 알고리즘

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[GoF] 팩토리 메서드 패턴(Factory Method Pattern)

장장스 — Sun, 5 Dec 2021 20:03:13 +0900

팩토리 메서드 패턴(Factory Method Pattern)

팩토리 메서드 패턴이란?

인스턴스 생성을 하위 클래스로 분리하도록 위임하는 패턴이다. 인스턴스를 생성하기 위한 인터페이스를 정의하고자 하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정을 하위 클래스에서 결정하도록 할 수 있습니다.

(비유하자면 고객이 자량 구매를 요청 했을 때, 공장에서 요청에 맞게 차량을 생산하는 것과 같다.)

팩토리 메서드 패턴 왜 사용할까?

인스턴스를 생성할 때 관련된 동일한 메서드는 상위 클래스에서 처리하여 공통처리되도록 구현이 가능하고, 나머지 상황에 따른 각각 일어날 수 있는 인스턴스에 대한 생성을 하위 클래스에게 처리할 수 있습니다.

팩토리 메서드 패턴을 사용하게 되면

하위 클래스에서 상황에 따라 다양한 인스턴스를 생성할 수 있다.

클래스 다이어그램

객체 협력

Product 팩토리 메소드가 생성하는 객체의 인터페이스를 정의하는 abstract 클래스
ConcreteProduct Product 클래스에 정의된 인터페이스를 실제로 구현한다.
Creator Product 타입의 객체를 반환하는 팩토리 메소드를 선언한다. Creator 클래스는 팩토리 메소드를 기본적으로 구현하는데, 이 구현에서는 ConcreateProduct 객체를 반환한다.
ConcreteCreator ConcreteProduct 의 인스턴스를 반환하기 위해 팩토리 메소드를 재정의 한다.

코드보기 Click!

GIT COMMIT 링크 열기!

[ GoF] 템플릿 메서드 패턴(Template Method Pattern)

장장스 — Sat, 4 Dec 2021 13:40:08 +0900

템플릿 메서드 패턴(Template Method Pattern)

템플릿 메서드 패턴이란?

상위 클래스(abstract class)에서 전반적인 흐름을 구현하고 하위 클래스에서 이를 상속받아 구체적인 처리를 하도록 위임하는 패턴이다.

템플릿 메서드 패턴 왜 사용할까?

오퍼레이션에 알고리즘(단계)의 기본 골격 구조를 정의하고 구체적인 단계는 하위 클래스에 정의한다. abstract 메서드를 통해서 알고리즘(단계)의 일부 단계를 정의함으로써 템플릿 메소드의 처리순서를 정할 수 있다.

템플릿 메서드를 사용하게 되면

템플릿 메서드를 통해 코드 재사용을 할 수 있다.
프레임워크에서 가장 많이 사용되는 패턴 중 하나 이다.
클래스의 공통부분을 분리할 수 있다.
템플릿 메서드에서 사용하는 오퍼레이션들
- ConcreteClass 오퍼레이션이나 클라이언트 클래스에 정의된 오퍼레이션
- AbstractClass 에 정의된 오퍼레이션 중 구체적인 알고리즘을 가지고 있는 오퍼레이션 : final을 선언하여 재정의 할 수 없게 한다.
- 기본 오퍼레이션으로 추상화된 오퍼레이션 : abstract 메서드를 말함.
- 훅 오퍼레이션 : 상위 클래스에서 빈 메서드를 정의함. 필요한 경우 하위 클래스에서 재정의 하여 사용할 수 있다.

클래스 다이어그램

객체 협력

AbstractClass 하위 클래스에서 반드시 구현해야 하는 알고리즘 처리 단계 내의 기본 오퍼레이션이 무엇인지를 정의한다. 하위 클래스에서 이들 오퍼레이션들을 구현한다.
ConcreteClass 상위 클래스의 abstract 메서드를 구현하거나 구현된 메서드를 재정의(@Override)한다

코드보기 Click!

GIT COMMIT 링크!

[GoF] 빌더 패턴(Builder Pattern)

장장스 — Fri, 3 Dec 2021 13:30:41 +0900

빌더 패턴(Builder Pattern)

빌더 패턴이란?

복잡한 객체를 생성하는 클래스와 구현하는 클래스를 분리하여, 동일한 생성 과정에서도 서로 다른 결과물이 나올 수 있도록 방법을 제공합니다. 사용자는 Builder에서 제공하는 메서드를 사용하여 (구현)결과물을 얻을 수 있습니다.

빌더 패턴 왜 사용할까?

객체를 생성할 때 생성 과정과 구현 방법을 분리함으로써 동일한 객체를 생성에서 과정에서 여러 다른 표현이 나올 수 있다.

빌더 패턴을 사용하게 되면

생성과 구현을 분리할 수 있다.
구현을 다양하게 할 수 있다.
복잡한 객체를 생성하는 절차를 세밀하게 나눌 수 있다.
사용자는 구체적인 사항을 알 필요가 없다.

클래스 다이어그램

객체 협력

Builder Product의 각 요소들을 생성하는데 필요한 추상 메서드가 선언된 클래스나 인터페이스
ConcreteBuilder Builder에 선언된 메서드를 구현한 클래스
Director Builder 인터페이스를 사용하여 Product를 생성한다.
Product 결과물

이펙티브 자바에서 사용하는 빌더 패턴

이팩티브 자바 책에서도 빌더 패턴이 등장한다.

책에서의 빌더 패턴은 객체를 생성할 때 여러개의 매개 변수가 점진적으로 늘어나는 경우 여러개의 생성자를 만들어 사용하기 보다 인스턴스 생성을 위한 Builder를 사용함으로써, 매개 변수의 개수에 상관없이 유연하게 수정하며 혹시 모를 오류를 방지하는 구조를 제공하는 것을 말한다.

GoF의 Builder 패턴은 생성자 뿐만아니라 일련의 과정을 추상화하여 인스턴스를 생성한다는 차이가 있다.

코드보기 Click!

Github 커밋 링크!

[OS] 메모리 불연속할당 - (3) 페이지드 세그먼테이션

장장스 — Thu, 2 Dec 2021 19:16:20 +0900

[OS] 메모리 불연속할당 - (3) 페이지드 세그먼테이션

안녕하세요? 장장스입니다.

실제 물리적 메모리는 크게 연속할당 방식과 불연속할당 방식으로 나뉩니다.

오늘은 메모리 불연속할당 방식중 하나인 페이지드 세그먼테이션에 대해 정리해보겠습니다.

페이지드 세그먼테이션

앞선 두 가지 포스팅을 보면

(1) 페이징 기법

(2) 세그먼테이션

각각의 장단점을 갖고 있음을 알 수 있다. 페이지드 세그먼테이션은 페이징 기법과 세그먼테이션 기법의 장점을 취하는 주소 변환 기법이다.

세그먼테이션과 마찬가지로 프로세스를 의미 단위의 세그먼트로 분할한다. 단, 세그먼테이션 처럼 불규칙한 길이가 아니라 동일한 크기의 페이지들의 집합으로 구성하는 것이다.

페이지드 세그먼테이션 테이블

하나의 세그먼트를 여러개의 페이지로 구성되므로 페이지드 세그먼테이션은 2개의 테이블을 사용한다.

외부의 세그먼트 테이블
내부의 페이지 테이블

페이징 기법의 2단계 페이지 테이블과 유사한 구조를 사용한다.

페이지드 세그먼테이션 테이블을 활용하여 주소변환 하는 과정은 다음과 같다.

1. 논리적 주소의 상위 비트인 세그먼트 번호를 통해 세그먼트 테이블의 해당 항목을 확인한다.

2. 해당 항목에는 세그먼트의 길이와 세그먼트의 페이지 테이블 시작 주소가 있다.

3. 세그먼트 길이를 넘어선 메모리 접근인지 체크한다. 유효하지 않다면 트랩을 발생시킨다.

4. 오프셋 값을 상위/하위 비트로 나누어 상위비트는 세그먼트 내의 페이지 번호로 사용하고, 하위 비트는 페이지 내에서의 변위로 사용한다.

Post

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 메모리 불연속할당 - (2) 세그먼테이션

장장스 — Wed, 1 Dec 2021 18:37:32 +0900

[OS] 메모리 불연속할당 - (2) 세그먼테이션

안녕하세요? 장장스입니다.

실제 물리적 메모리는 크게 연속할당 방식과 불연속할당 방식으로 나뉩니다.

오늘은 메모리 불연속할당 방식중 하나인 세그먼테이션에 대해 정리해보겠습니다.

세그먼테이션

세그먼테이션은 프로세스의 주소공간을 의미 단위의 세그먼트(segment)로 나누어 물리적 메모리에 올리는 방법이다.

프로세스의 주소 공간은 일반적으로 코드, 데이터, 스택 등의 의미 있는 단위들로 구성이 된다. 세그먼트는 이와 같은 주소 공간 전체를 크게는 하나의 세그먼트로 보기도 한다. 일반적으로 코드, 데이터, 스택 등의 기능 단위로 세그먼트를 정의하며, 프로그램을 구성하는 함수 하나하나를 각각 세그먼트라고 정의할 수도 있다. 주의할 점은 논리적 단위로 나눈 것이기 때문에 세그먼트의 크기가 균일하지 않다는 점이다.

세그먼트 테이블

세그먼테이션 기법에서는 주소 변환을 위해 세그먼트 테이블을 사용한다. 세그먼트 테이블의 각 항목은 기준점(base)과 한계점(limit)을 가지고 있다.

기준점(base) : 물리적 메모리에서 세그먼트의 시작 위치
한계점(limit) : 세그먼트의 길이

세그먼테이션 기법에서는 세그먼트 길이가 균일하지 않으므로 세그먼트의 시작 위치 정보뿐 아니라 길이 정보도 함께 보관하고 있는 것이다.

페이징 기법에서는 주소 변환을 위해 기준 레지스터(PTBR)와 테이블 길이 레지스터(PTLR)를 사용했듯이 세그먼테이션 기법에서도 세그먼트 테이블 기준 레지스터(STBR)과 세그먼트 테이블 길이 레지스터(STLR)를 사용하게 된다.

세그먼트 테이블 기준 레지스터(STBR) : 프로세스의 세그먼트 테이블 메모리 위치(시작 주소)
세그먼트 테이블 길이 레지스터(STLR) : 프로세스 세그먼트의 총 개수

세그먼트 테이블 주소 변환

세그먼테이션 기법에서는 논리적 주소를 물리적 주소로 변환하기 전에 두 가지 항목을 체크합니다.

1. 요청된 세그먼트의 번호가 STLR 미만의 값인지 확인합니다. 만약 그렇지 않다면 존재하지 않는 세그먼트에 대한 접근으로 예외상황을 발생시켜 메모리에 접근 봉쇄합니다.

2. 논리적 주소의 오프셋 값이 그 세그먼트의 길이보다 작은 값인지 확인합니다. 만약 그렇지 않다면 세그먼트 테이블의 길이를 넘어서는 오프셋 위치에 대한 접근으로 예외상황을 발생시켜 메모리에 접근 봉쇄합니다.

장단점

세그먼트는 의미 단위로 나누어져 있기 때문에 공유와 보안의 측면에서 페이징 기법에 비해 효과적이다. 주소 공간의 일부를 공유하거나 특정 주소 공간에 접근 제어를 할경우 크기가 아니라 의미 단위로 공유되기 떄문이다.

세그먼테이션은 프로세스를 의미 단위로 나누어 메모리에 적재하기 때문에 세그먼트의 길이가 균일하지 않다. 따라서 물리적 메모리 관리에서 외부조각이 발생하게 되며, 세그먼트를 어느 가용 공간에 할당할 것이지 결정하는 문제가 발생한다.

Post

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 메모리 불연속할당 - (1) 페이징 기법

장장스 — Tue, 30 Nov 2021 15:38:42 +0900

[OS] 메모리 불연속할당 - (1) 페이징 기법

안녕하세요? 장장스입니다.

실제 물리적 메모리는 크게 연속할당 방식과 불연속할당 방식으로 나뉩니다.

오늘은 메모리 불연속할당 방식중 하나인 페이징 기법에 대해 정리해보겠습니다.

메모리 불연속할당 기법

불연속할당 기법은 하나의 프로세스가 물리적 메모리의 여러 위치에 분산되어 올라갈 수 있는 메모리 할당 기법을 말합니다.

페이징 기법

페이징 기법은 프로세스의 주소 공간을 동일한 크기의 페이지 단위로 나누어 물리적 메모리의 서로 다른 위치에 페이지들을 저장하는 방식을 말한다. 페이징 기법에서는 각 프로세스의 주소 공간 일부는 백킹스토어에, 일부는 물리적 메모리에 혼재시키는 것이 가능하다.

페이징 기법에서는 물리적 메모리를 페이지와 동일한 크기의 프레임으로 미리 나누어 둔다.

메모리에 올리는 단위가 동일한 크기의 페이지 단위이므로, 메모리를 같은 크기로 미리 분할해 두더라도 빈 프레임이 있으면 어떤 위치이든 사용될 수 있기 때문이다.

따라서 페이징 기법은 동적 메모리 할당 문제(메모리 주소 공간 결정 문제)가 발생하지 않는다는 강점을 가진다. 빈 페이지가 보이면 메모리를 올리기만 하면 된다.

페이징 기법에서는 프로세스의 주소 공간과 물리적 메모리가 모두 같은 크기의 페이지 단위로 나누어지기 때문에 빈 공간은 어느 곳이든 활용 할 수 있다. 따라서 메모리상의 가용 공간의 크기가 작아서 빈 공간임에도 활용되지 못하는 외부조각 문제가 발생하지 않는다. 그러나 프로그램의 크기가 항상 페이지 크기의 배수가 된다는 보장이 없기 때문에 프로세스의 주소 공간 중 제일 마지막에 위치한 페이지에서는 내부조각이 발생할 가능성이 있다.

주소 변환 기법

페이징 기법에서는 주소 변환 절차가 연속할당 방식에 비해 다소 복잡하다. 이는 하나의 프로세스라 하더라도 페이지 단위로 물리적 메모리에 올리는 위치가 상이 하므로, 논리적 주소를 물리적 주소로 변환하는 작업이 페이지 단위로 이루어져야 하기 때문이다. 즉, 특정 프로세스의 몇 번째 페이지가 물리적 메모리의 몇 번째 프레임에 들어 있다는 페이지별 주소 변환 정보를 유지하고 있어야 한다. 따라서 페이징 기법에서는 모든 프로세스가 각각의 주소 변환을 위한 페이지 테이블(page table)을 가지며, 이 테이블은 프로세스가 가질 수 있는 페이지의 개수만큼 주소 변환 엔트리를 가지고 있게 된다.

페이징 기법에서는 CPU가 사용하는 논리적 주소를 페이지 번호(p)와 페이지 오프셋(d)로 나누어 주소변환을 사용한다.

1. 페이지 테이블에서 페이지 번호(p)를 확인하여 물리적 메모리 상의 기준 주소(base address)를 확인한다.

2. 물리적 주소에서 오프셋(d)만큼 떨어진 곳이 실제 물리적 메모리 주소이다.

페이지 테이블

페이지 테이블에 접근하기 위해 운영체제는 2개의 레지스터를 사용한다. 이들은 각각

페이지 테이블 기준 레지스터(page table base register) : 페이지 테이블의 시작 위치
페이지 테이블 길이 레지스터(page table length register) : 페이지 테이블의 크기

기능을 갖고 있다.

그렇다면 페이지 테이블은 어디에 있을까❓

페이지 테이블은 메모리에 존재한다. 즉, 실제 물리적 메모리의 주소를 알기 위해서

1. 페이지 테이블 정보를 확인하기 위해 메모리 접근

2. 물리적 메모리를 얻기 위해 메모리 접근

총 2번의 메모리 접근을 하게되는 오버헤드가 발생한다. 이와 같은 문제를 해결하기 위해 TLB(Translation Look-aside Buffer)라고 불리는 고속의 주소 변환용 하드웨어 캐시를 사용한다.

TLB 하드웨어는 가격이 비싸서 용량이 적다. 따라서 TLB에서 모든 페이지 테이블 정보를 확인 할 수는 없다. 또 원하는 페이지를 찾기 위해 모든 페이지를 뒤져야하게 되는데 페이지 테이블 개수가 n개 라면 O(n)의 시간 복잡도가 걸리게 된다. 이를 극복하기 위해 병렬탐색이 가능한 연관 레지스터를 사용하여 모든 페이지 테이블 정보를 한꺼번에 찾는다.

TLB를 확인해도 원하는 페이지 정보를 확인 할 수 없다면 페이지 테이블을 방문하여 물리적 메모리 주소를 확인한다.

계층적 페이징

현대의 컴퓨터는 32bit 혹은 64bit 주소 체계를 사용한다. 32bit 컴퓨터에서는 2^32byte(4GB)의 주소 공간을 갖는 프로그램을 지원할 수 있다. 이러한 컴퓨팅 환경에서 페이지 크기가 4KB라면 4GB/4KB = 1M(2^20)개의 페이지 테이블이 필요하게 된다. 각 페이지 테이블 항목이 4byte씩 필요로 한다면 한 프로세스당 필요한 페이지 수는 4MB의 공간을 필요로 하게 된다.

32bit 운영체제는 2^32byte의 주소공간 즉, 4GB의 주소공간을 갖는 프로그램을 지원한다.

프로세스 주소공간 4GB
페이지 크기 4KB
페이지 테이블 항목당 필요한 용량 4byte

4GB/4KBx4byte = 4MB

사용하는 프로세스가 증가할수록 페이지 테이블을 위한 많은 메모리 공간이 사용된다. 이러한 메모리 낭비를 줄이기 위해 2단계 페이징 기법을 사용한다. 2단계 페이징 기법은 외부 페이지 테이블과 내부 페이지 테이블을 사용한다. 사용되지 않는 주소 공간에 대해서는 외부 페이지 테이블의 항목을 NULL로 설정하여 대응되는 내부 페이지 테이블을 생성하지 않는 방법이다.

계층적 페이징 기법은 메모리 공간을 줄여 공간적인 이득을 볼 수 있지만 주소 변환을 위해 페이지 단계수가 3단계, 4단계로 증가할 수록 메모리에 접근하는 횟수도 증가하여 오버헤드가 증가하는 손해가 뒤따르게 된다.

그러므로 TLB와 계층적 페이징 기법을 적절히 사용하여 메모리 공간 효율과 시간 효율을 높여야 한다.

역페이지 테이블

역페이지 테이블 기법은 물리적 메모리의 페이지 프레임 하나당 페이지 테이블에 하나씩 항목을 두는 방식이다. 다시 말하면 논리적 주소에 대해 페이지 테이블을 만드는 것이 아니라, 물리적 주소에 대해 페이지 테이블을 만드는 것이다.

역페이지 테이블❓
논리적 주소에 대한 페이지 테이블 ❌
물리적 주소에 대한 페이지 테이블 ✔️

즉, 프로세스마다 페이지 테이블을 두지 않고, 시스템 전체에 페이지 테이블을 하나만 두는 방법이다.

페이지 테이블의 각 항목은 프로세스 번호(pid)와 프로세스 내의 논리적 페이지 번호(P)를 담고 있게 된다.

역페이지 테이블을 사용하기 위해 모든 페이지를 탐색해야 하므로 시간적으로 손해를 보게 된다. 이를 해결하기위해 역페이지 테이블은 병렬 탐색을 가능하게 하는 연관 레지스터를 사용하여 시간적 효율성을 높이게 된다.

공유 페이지

공유 페이지란 공유 코드를 담고 있는 페이지를 말한다. 공유 페이지는 여러 프로세스에 의해 공유되는 페이지이므로 물리적 메모리에 하나만 적재되어 메모리를 좀 더 효율적으로 사용할 수 있게 한다.

메모리 보호

페이지 테이블에는 주소 변환을 위한 정보 뿐만 아니라 메모리 보호를 위한 보호비트(protection bit)와 유효 무효 비트(valid-invalid bit)를 두고 있다.

보호비트(protection bit)는 각 페이지에 대한 접근 권한의 내용을 담고 있다. 각 페이지에 대한 접근을 허용하는지의 정보가 보호비트에 저장된다. 다시 말해 각 페이지에 대한 읽기/쓰기 등의 접근 권한을 설정하는 데에 사용된다.

유효 무효 비트(valid-invalid bit)는 해당 페이지의 내용이 유효한지에 대한 내용을 담고 있다. '유효'로 설정되어 있으면 메모리에 해당 페이지가 존재함을 뜻하며, '무효'일 경우 프로세스가 주소 부분을 사용하지 않거나, 해당 페이지가 백킹스토어에 존재하여 접근 권한이 없다는 의미로 사용된다.

Post

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 메모리 연속할당 - 고정분할 방식과 가변분할 방식

장장스 — Sun, 28 Nov 2021 16:24:03 +0900

[OS] 메모리 연속할당 - 고정분할 방식과 가변분할 방식

안녕하세요? 장장스입니다.

실제 물리적 메모리는 크게 연속할당 방식과 불연속할당 방식으로 나뉩니다.

오늘은 메모리 연속할당 방식인 고정분할 방식과 가변분할 방식에 대해 정리해보겠습니다.

메모리 연속할당 기법

연속할당 기법은 프로세스를 메모리에 올릴 때 주소 공간을 메모리의 한 곳에 연속적으로 적재하는 방식입니다. 연속 할당 방식에서는 물리적 메모리를 다수의 분할로 나누어 하나의 분할에 하나의 프로세스가 적재되도록 합니다.

연속할당 기법은 크게 고정분할 방식과 가변분할 방식으로 나뉩니다.

고정분할 방식

고정분할 방식은 물리적 메모리를 정해진 개수만큼의 영구적인 분할로 나누어두고 각 분할에 하나의 프로세스를 적재하는 방식입니다. 분할의 크기는 모두 동일할 수도 있고 서로 다를 수도 있습니다.

고정분할 방식은 동시에 메모리에 올릴 수 있는 프로그램의 수가 고정되어 있으며 수행 가능한 프로그램의 최대 크기 또한 제한된다는 점에서 가변분할 방식에 비해 융통성이 떨어집니다.

또한 고정분할 방식에는 외부조각과 내부조각 문제가 발생할 수 있습니다.

가변분할 방식

가변분할 방식은 메모리에 적재되는 프로그램의 크기에 따라 분할의 크기, 개수가 동적으로 변하는 방식이다. 따라서 가변분할 방식은 프로그램의 크기를 고려해서 메모리를 할당하고 이를 기술적으로 관리할 수 있는 기법이 필요하다.

가변분할 방식은 프로세스에 딱 맞게 메모리 공간을 사용하기에 내부조각 문제는 발생하지 않는다. 그러나 사용중인 프로세스가 종료되어 메모리에 새로운 프로세스를 올릴 메모리 공간이 충분하지 않을 경우 외부 조각 문제가 발생한다.

가변분할 방식은 어디 메모리 공간에 프로세스를 올려야 할지 결정해야하는 문제가 있다. 이를 해결하기 위한 기술적 방법으로 다음과 같이 3가지가 있다.

최초적합: 가장 먼저 나오는 가용 가능한 메모리 공간에 프로세스를 올리는 방법이다.
최초적합: 가장 딱 맞는 메모리 공간을 찾아 프로세스를 올리는 방법이다.
최초적합: 가장 큰 메모리 공간에 프로세스를 올리는 방법이다.

가변분할 방식에서 발생하는 외부조각 문제를 해결하기 위한 방법으로 컴팩션(compaction: 압축)방법이 있다. 물리적 메모리 중에서 사용중인 메모리 공간을 한쪽으로 몰고 가용 공간을 확보하는 방법이다. 메모리를 효율적으로 사용할 수 있는 측면에서는 좋은 선택이지만 수행중인 프로세스의 메모리 주소 공간을 이동시켜야 하므로 비용이 매우 많이 든다.

Post

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[백준] 2461 대표선수 #JAVA #투포인터

장장스 — Sat, 27 Nov 2021 08:01:46 +0900

[백준] 2461 대표선수 #JAVA #투포인터

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.List;
import java.util.StringTokenizer;

public class Main {

	static int N,M;
	static int count[];
	
	public static void main(String[] args) throws IOException{
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		
		StringTokenizer st;
		
		st= new StringTokenizer(br.readLine());
		
		N = Integer.parseInt(st.nextToken());//학급
		M = Integer.parseInt(st.nextToken());//학급별 학생 수
		count = new int[N];
		
		List<int[]> student = new ArrayList<>();  
		
		for (int i = 0; i < N; i++) {
			st = new StringTokenizer(br.readLine());
			
			for (int j = 0; j < M; j++) {
				student.add(new int[] {i,Integer.parseInt(st.nextToken())}); //학급,능력치
			}
		}

		student.sort((a,b)-> a[1]-b[1]); // 능력치 순서로 정렬
		
		int lp = 0;
		int rp = 0;

		int diff= Integer.MAX_VALUE;
		
		while (lp < N*M-1 && rp < N*M-1) {

			//모든 학급이 포함되도록 rp값 이동
			while (rp < N*M-1) {
				
				count[student.get(rp++)[0]]++;
				
				if(haveAllClass()) break;
			}
			
			//모든 학급이 포함되도록 lp값 이동
			while (count[student.get(lp)[0]]>1) {
				count[student.get(lp++)[0]]--;
			}

			//모든 학급 포함시 값 갱신
			if(haveAllClass()) {
				int min = Integer.MAX_VALUE;
				int max = Integer.MIN_VALUE;
				
				for (int i = lp; i < rp; i++) {
					min = Math.min(min, student.get(i)[1]);
					max = Math.max(max, student.get(i)[1]);
				}
				diff = Math.min(diff, max-min);
			}
			
			//lp 오른쪽으로 한칸 이동
			count[student.get(lp++)[0]]--;
			
		}
		System.out.println(diff);
		
	}

	private static boolean haveAllClass() { //모든 학급이 포함되었는지 확인하는 함수
		for (int cnt : count) {
			if(cnt == 0) return false;
		}
		
		return true;
	}
}

풀이

능력치 순서대로 학생을 정렬한다. 이 때 학급의 정보를 확인 할 수 있어야 한다.
투 포인터를 활용하여 모든 학급의 학생이 포함되는 연속된 범위를 찾아낸다.
해당 범위에서 최댓값-최솟값 이 최소가 되는 값을 갱신한다.

주의 사항

lp, rp 범위 주의

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 메모리 스왑(스와핑) #swap

장장스 — Fri, 26 Nov 2021 09:59:39 +0900

[OS] 메모리 스왑(스와핑) #swap

안녕하세요? 장장스입니다.

오늘은 메모리 스와핑에 대해 정리해보겠습니다!

스와핑 (swapping)

메모리에 올라온 프로세스의 주소 공간 전체를 디스크의 스왑 영역(swap area)에 일시적으로 내려놓는 것을 말한다. 이때 스왑 영역은 백킹스토어(backing store)라고 부르며, 디스크 내에 파일 시스템과는 별도로 존재하는 일정 영역을 말한다.

잠깐❗
스와핑이라는 개념은 프로세스가 종료되어 그 주소 공간을 디스크로 내쫓는 것이 아니라, 특정한 이유로 수행 중인 프로세스의 주소 공간을 일시적으로 메모리에서 디스크로 내려놓는 것을 의미한다.

역할

그렇다면 스와핑의 역할은 무엇일까?

스와핑은 다중 프로그래밍의 정도(degree of multiprogramming)을 조절한다. 다시 말하면 메모리에 존재하는 프로세스의 수를 조절하는 것이다.

너무 많은 프로그램에 메모리에 동시에 올라오게 되면 한정된 메모리의 양을 적게 사용하게 될 것이다. 이는 시스템의 성능을 크게 떨어뜨린다. 스와핑은 이러한 문제를 해결하기 위해 몇몇 프로그램을 통째로 디스크의 스왑 영역으로 보냄으로써 메모리에 있는 프로그램들에게 실행에 필요한 적절한 메모리 공간을 보장한다. 현재 메모리에 있는 프로그램이 충분히 실행되고 나면 디스크 영역에 보낸 프로그램을 스왑 인 시켜 다시 메모리에 올린다.

스와핑 과정

1. 스와퍼(swapper)라고 불리는 중기 스케줄러에 의해 스왑 아웃시킬 프로세스를 선택한다.

(중기 스케줄러는 메모리에 적재된 프로세스의 수를 동적으로 조절하기 위한 스케줄러이다.)

2. 스와퍼가 선택한 프로세스에게 할당된 메모리 주소 공간을 통째로 빼앗아 디스크의 스왑 영역으로 스왑 아웃(swap out)시킨다.

3. 여유가 생긴 메모리 공간에 필요한 프로세스의 메모리 주소 공간을 스왑 인(swap in) 시킨다.

Post

References

[KOCW] 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[DB] 트랜잭션의 장애와 복구

장장스 — Thu, 25 Nov 2021 12:36:18 +0900

트랜잭션의 장애와 복구

트랜잭션 장애와 복구

트랜잭션 동작 시 장애가 발생하면 어떻게 해야 할까. 보통 로그를 통한 복구를 진행하게 된다. 복구 방법으로 REDO 복구와 UNDO 복구가 있다. DBMS는 어떻게 복구를 해야할지 판단한 후 REDO와 UNDO를 통해 복구를 진행하게 된다.

DBMS의 페이지 버퍼

데이터베이스 시스템은 보통 비휘발성 저장 장치인 디스크에 데이터를 저장하며 전체 데이터베이스의 일부분을 메인 메모리에 유지한다.

DBMS는 데이터를 고정 길이의 페이지(page)로 저장하며, 디스크에서 읽거나 쓸 때에 페이지 단위로 입출력이 이루어진다.

메인 메모리에 유지하는 페이지들을 관리하는 모듈을 보통 페이지 버퍼(page buffer) 관리자 또는 버퍼 관리자라고 부르는데, DBMS의 많은 주요 모듈 중에서 매우 중요한 모듈 중의 하나이다.

DBMS는 각 제품마다 구조가 다르기는 하지만, 크게 질의 처리기(Query Processor)와 저장 시스템(Storage System)으로 나눠볼 수 있다.

UNDO의 필요성

오퍼레이션 수행 중에 수정된 페이지들이 버퍼 관리자의 버퍼 교체 알고리즘에 따라서 디스크에 출력될 수 있다. 다음과 같은 2가지 정책이 있다.

STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책 ✔️
-STEAL: 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책

-STEAL 정책의 경우 트랜잭션 종료 전에 수정된 페이지들을 디스크에 쓰지 않는다면, 장애 발생 시 디스크 페이지에 반영되지 않아 로그 파일을 토대로 재실행 하여 해결 할 수 있다. 이 부분은 매력적이지만 이 정책은 매우 큰 크기의 메모리 버퍼가 필요하다는 문제점을 가지고 있다.

그렇다보니 대부분의 DBMS는 STEAL 버퍼 관리 정책을 선택한다. 트랜잭션 시 변경 사항을 로그에 기록하며, 디스크 페이지에 변경사항을 적용하게 된다. 즉 장애 발생으로 트랜잭션이 중단 되면 아직 완료되지 않은 트랜잭션이 수정한 페이지들도 디스크에 출력될 수 있는 문제가 생긴다. 이를 해결 하기 위해 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션의 원자성(Atomicity)에 근거하여 변경한 페이지들은 원상 복구되어야 한다. STEAL 정책은 수정된 페이지가 어떠한 시점에도 디스크에 써질 수 있기 때문에 장애 발생시 트랜잭션의 원자성을 해치게 된다.

위에서 말한 복구가 UNDO(뜻:원상태로 되돌리다)라고 한다. UNDO복구는 UNDO로그를 역순으로 실행하여 원상태로 복구하게 된다.

REDO의 필요성

REDO 복구는 UNDO 복구의 반대 개념이다. 커밋한 트랜잭션의 수정은 어떤 경우에도 지속(durability)되어야 한다. 이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구라고 하는데, REDO 복구 역시 UNDO 복구와 마찬가지로 버퍼 관리 정책에 영향을 받는다. 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에도 쓸 것인가 여부로 두 가지 정책이 구분된다.

FORCE: 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
-FORCE: 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책 ✔️

여기서 주의 깊게 봐야 할 부분은 -FORCE 정책이 수정했던 페이지(데이터)를 디스크에 반영하지 않는다는 점이다. (어떤 일들을 했었다고 하는 로그는 기록하게 되다.)

FORCE 정책을 따르면 트랜잭션이 커밋되면 수정되었던 페이지들이 이미 디스크 상의 데이터베이스에 반영되었으므로 REDO 복구가 필요 없게 된다. 반면에 -FORCE 정책을 따른다면 커밋한 트랜잭션의 내용이 디스크 상의 데이터베이스 상에 반영되어 있지 않을 수 있기 때문에 반드시 REDO 복구가 필요하게 된다.

트랜잭션에 대한 로그가 모두 기록되었으나 트랜잭션이 완료 되는 순간 장애가 발생하는 경우 REDO복구를 통해 복구를 진행 할 수 있다.

(그러면 디스크 반영은 언제 하는 거쥬? 아시는 분 댓글 좀 ㅎㅎ.. )

로그

UNDO 복구와 REDO 복구를 위해서 가장 널리 쓰이는 구조는 보편적으로 사용되는 기법은 로그(log)이다. DBMS에서 사용되는 3가지 로깅 방법이다.

물리적인 상태 로깅(physical state logging)

이 방법은 DBMS에서 가장 널리 쓰이는 기본적인 로깅 방법이다.

갱신 이전 이미지와 이후 이미지를 모두 다 가지고 있으며, UNDO 복구 때에는 이전 이미지로 현재 이미지를 대체하며, REDO 복구 때에는 이후 이미지를 반영하는 방식으로 복구가 이루어진다. 물리적인 상태 로깅은 이전 이미지 혹은 이후 이미지로 단순히 대체하는 작업으로 이해하면 된다.

물리적인 전이 로깅(physical transition logging)

이 방법은 페이지 혹은 레코드에 대해서 XOR 차이점을 기록하는 방식으로 이루어진다. 복구 시점에서 로그 레코드에 기록된 XOR 이미지와 레코드 이미지를 이용하여 UNDO 복구와 REDO 복구를 수행하게 된다.

논리적인 전이 로깅(logical transition logging)

이 방법은 오퍼레이션 로깅(operation logging)으로도 불리는데, 어떤 일을 했었는가를 기록하는 방식이다. 예를 들어, a = a + 1과 같은 연산을 로깅할 때 이전 값 0, 이후 값 1을 물리적으로 기록할 수도 있고, a = a + 1 이라는 연산 그 자체를 기록할 수 있다. 이러한 논리적인 로그에 대한 복구 작업은 REDO를 위하여 로그 레코드에 기록된 오퍼레이션을 재수행하거나, UNDO를 위하여 역 오퍼레이션을 수행하는 방식으로 이루어진다.

Post

2021.11.23 - [database/DB Concept] - [DB] 트랜잭션

References

[OS] 주소 바인딩

장장스 — Wed, 24 Nov 2021 09:58:05 +0900

[OS] 주소 바인딩

안녕하세요? 장장스입니다.

오늘은 주소 바인딩에 대해 정리해보겠습니다.

주소 바인딩

프로그램이 메모리에 적재되면 해당 프로세스의 독자적인 주소 공간이 생성됩니다. 이 주소를 논리적 주소(logical address) 혹은 가상 주소(virtual address)라고 합니다. 논리적 주소는 프로세스마다 독립적으로 할당되며 0부터 시작합니다. 물리적 주소(physical address)는 실제 물리적 메모리에 올라가는 위치를 말합니다.

CPU가 기계어 명령을 수행하기 위해 논리적 주소를 통해 메모리 참조를 하게 되면 해당 논리적 주소가 물리적 메모리의 어느 위치에 매핑되는지 확인해야 합니다. 이렇게 프로세스의 논리적 주소를 물리적 메모리 주소로 연결시켜주는 작업을 '주소 바인딩'이라고 합니다.

주소 바인딩의 방식은 물리적 메모리 주소가 결정되는 시기에 따라 3가지로 나뉜다.

주소 바인딩 방법 3가지

컴파일 타임 바인딩 (compile time binding)

컴파일을 하는 시점에 해당 프로그램이 물리적 메모리의 몇 번지에 위치할 것인지를 결정한다. 절대코드를 생성하는 바인딩이라고도 부른다. 물리적인 메모리 위치를 변경하려면 컴파일을 다시해야한다.

로드 타임 바인딩 (load time binding)

프로그램의 실행이 시작될 때에 물리적 메모리 주소를 결정한다. 로드 타임 바인딩 방식에서는 로더(loader)의 책임하에 물리적 메모리 주소가 부여되며 프로그램이 종료될 때까지 물리적 메모리상의 위치가 고정된다.

실행시간 바인딩 (run time binding)

프로그램이 실행을 시작한 후에도 그 프로그램이 위치한 물리적 메모리상의 주소가 변경될 수 있는 바인딩 방식이다. CPU가 메모리 주소를 참조하기 위해 주소 매핑 테이블을 이용해 바인딩을 점검한다.

실행시간 바인딩을 사용하기 위해 기준 레지스터(base register), 한계 레지스터(limit register), MMU(Memory Management Unit)와 같은 하드웨어를 이용한다.

MMU의 물리적 주소 계산

사진처럼 MMU는 기준 레지스터에 논리적 주소를 더해 실제 물리적 주소값을 얻어내는 하드웨어다.

예를 들어 기준 레지스터의 값이 17000일 때 논리적 주소가 186이라면 물리적 주소는 17186이 된다. 이때 물리적 메모리의 시작 위치인 기준 레지스터를 재배치 레지스터(relocation register) 라고도 부른다.

한계 레지스터는 현재 수행중인 프로세스의 논리적 주소의 최댓값으로 프로세스의 크기를 담고 있다. 또 한계 레지스터는 프로세스가 자신의 주소 공간을 넘어서는 메모리를 참조하려고 하는지 체크하여 메모리 보안을 이루는 용도로 사용된다.

프로세스 주소를 넘어서는 메모리를 참조하려고 하면 어떻게 될까❓
다른 프로세스를 메모리를 침범하게 된다. 뿐만 아니라 운영체제가 존재하는 메모리 영역을 변경하여 시스템에 심각한 영향을 끼칠 수 있다.

References

KOCW 운영체제 강의 - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[DB] 트랜잭션

장장스 — Tue, 23 Nov 2021 19:25:31 +0900

# A친구의 통장 잔액은 300,000원 일때,
UPDATE account
SET balance = balance - 500000
WHERE name = 'A';

[DB]트랜잭션

트랜잭션이란

데이터베이스 트랜잭션은 일반적으로 데이터베이스의 모든 변경 사항을 나타냅니다.

트랜잭션은 논리 또는 작업의 단일 단위이며 때로는 여러 작업으로 구성됩니다. 데이터베이스의 일관된 모드에서 수행되는 모든 논리적 계산을 트랜잭션이라고 합니다.

트랜잭션은 왜 필요할까?

친구에게 빌린 돈 10,000원을 이체했습니다. 그런데 예기치 못한 오류가 발생해 버렸습니다.

제 계좌에서는 10,000원이 출금되어 나갔는데 친구 계좌에는 입금이 되지 않았습니다.

이러한 상황이 발생하지 않도록 중간에 거래가 실패하면 처음의 상태로 되돌려야(rollback) 합니다.

ACID

트랜잭션은 ACID라 불리는 특성이 있습니다.

Atomicity(원자성)

트랜잭션 내의 모든 명령은 반드시 모두 수행되어야 하며, 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

------------------------------
START TRANSACTION;
------------------------------


------------------------------
#1.A의 통장에서 10,000원을 차감한다.
UPDATE account
SET balance = balance - 10000
WHERE name = 'A';
------------------------------


------------------------------
#2. B의 통장에서 10,000원을 받는다.
UPDATE account
SET balance = balance + 10000
WHERE name = 'B';
------------------------------


------------------------------
COMMIT;
------------------------------

친구A가 친구B에게 10,000원을 송금한다고 생각해 보면, #1.A의 통장에서 10,000원을 차감한다. #2.B의 통장에서 10,000원을 받는다 모두 성공해야만 합니다.

트랜잭션이 내에서 SQL이 단하나라도 실패했으면 트랜잭션 내의 SQL은 모두 취소(rollback)되어야 합니다.

즉, 트랜잭션 내에서의 모든 작업이 성공하거나, 실패해야만 합니다.

Consistency(일관성)

트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 말한다.

계좌 잔액 칼럼에는 잔액이 0원 이상이여야 한다는 룰이 걸려 있습니다.

A친구가 500,000원을 이체하려고 하는데, 실제 통장에는 300,000원 뿐입니다. 500,000원을 뺴니 잔액이 마이너스가 되며 잔액에 0원 이상이여야 한다는 룰을 위반하게 됩니다.

DBMS는 룰을 위반했으므로 트랙잭션을 취소합니다.

Isolation(독립성,격리성)

트랜잭션 여러개가 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들지 못하도록 보장한다.

10,000원을 이체하는 동시에 친구가 점심 밥 값으로 8,000원을 이체하고 있습니다. 두 개의 트랜잭션은 서로 다른 트랙잭션이므로 각각 동작해야 합니다.

Durablility(영속성,지속성)

성공적으로 수행된 트랜잭션은 영구적으로 반영되어야 한다.

Post

References

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] CPU 스케줄링

장장스 — Mon, 22 Nov 2021 09:56:57 +0900

CPU 스케줄링

안녕하세요? 장장스입니다.

오늘은 CPU 스케줄링을 정리해 볼게요!

CPU 스케줄러

CPU 스케줄러는 준비(ready) 상태에 있는 프로세스들 중 어떠한 프로세스에게 CPU를 할당할지 결정하는 운영체제의 코드입니다.

그렇다면 CPU 스케줄러는 어떻게 작동할까요❓

프로세스가 CPU를 할당 받고 기계어 명령을 수행하다가 타이머 인터럽트가 발생하면 CPU 스케줄러가 호출됩니다. 그러면 CPU 스케줄러는 준비 큐(ready queue)에서 CPU를 기다리는 프로세스 중 하나를 선택해 CPU를 할당하게 됩니다.

위와 같은 경우 말고도 CPU 스케줄링이 필요한 다양한 경우들이 있습니다.

1. 실행(run)상태에 있던 프로세스가 I/O 요청 등에 의에 봉쇄(blocked)상태로 바뀌는 경우

2. 실행(run)상태에 있던 프로세스가 타이머 인터럽트 발생에 의해 준비(ready)상태로 바뀌는 경우

3. I/O 요청으로 봉쇄(blocked)상태에 있던 프로세스가 I/O 작업이 완료되어 인터럽트가 발생하고 준비(ready)상태로 바뀌는 경우

4. CPU에서 실행(run)상태에 있는 프로세스가 종료되는 경우

비선점형(nonpreemptive) VS 선점형(preemptive)

CPU 스케줄링 방식에는 2가지 방식이 있습니다.

비선점형 방식(nonpreemptive)은 CPU를 획득한 프로세스가 스스로 CPU를 반납하기 전까지 CPU를 빼앗기지 않는 방법입니다.

선점형 방식(preemptive)은 프로세스가 CPU를 계속 사용하기를 원하더라도 강제로 빼앗을 수 있는 스케줄링 방법입니다.

디스패처 (dispathcer)

CPU 스케줄러가 다음 프로세스에게 CPU를 할당해야 할지 결정되면 실제로 CPU를 이양하는 작업이 필요합니다. 이러한 작업을 도와주는 운영체제의 코드를 디스패처(dispathcer)라고 합니다.

디스패처는 현재 수행중이던 프로세스의 문맥(context)을 PCB에 저장하고, 새로운 프로세스의 문맥(context)를 새로운 프로세스의 PCB로부터 복원 후 해당 프로세스에게 CPU를 넘기는 과정을 수행합니다.

스케줄링 알고리즘

(1) 선입선출 스케줄링 (FCFS) [비선점]

선입선출(First-Come First-Served) 스케줄링은 프로세스가 준비 큐에 도착한 순서대로 CPU를 할당하는 방식을 말한다.

먼저 온 요청을 먼저 처리하기 때문에 매우 합리적인 스케줄링 방식인 것 같지만 경우에 따라 비효율적인 결과를 초래하기도 한다. CPU 버스트가 긴CPU 사용 시간이 긴 작업) 프로세스 하나가 CPU 버스트가 짧은 프로세스 여러개보다 먼저 도착했다고 하자. 앞서 도착한 프로세스의 오랜 작업시간 동안 뒤에 있는 짧은 작업시간의 프로세스가 오랜 대기시간을 기다려야 하는 문제가 발생할 수 있다.

이처럼 FCFS 스케줄링 알고리즘은 먼저 도착한 프로세스의 성격에 따라 평균 대기시간이 크게 달라 질 수 있다.

(2) 최단작업 우선 스케줄링 (SJF) [비선점][선점]

최단작업 우선(Shortest-Job First) 스케줄링 알고리즘은 CPU 버스트가 가장 짧은 프로세스에게 제일 먼저 CPU를 할당하는 방식이다. 최단작업 우선 스케줄링(SJF)는 평균 대기시간을 가장 짧게 하는 최적 알고리즘으로 알려져 있다.

비선점형 방식 구현은 현재 작업중인 프로세스가 CPU를 할당받아 작업중일 때 CPU 버스트가 짧은 요청이 새로 들어와도 해당 프로세스의 작업이 끝날 때까지 CPU를 반납하지 않는 방식이다.

선점형 방식 구현은 현재 작업중인 프로세스에게 CPU를 할당했다 하더라도 새로 들어온 요청의 CPU 버스트가 더 짧을 경우 CPU를 빼앗아 더 짧은 프로세스에게 부여하는 방식이다. 이러한 SJF의 선점형 구현방식을 SRTF(Shortest Remaining Time First)라고도 부른다.

SJF 스케줄링은 다음과 같은 문제점이 있다.

1. 프로세스의 CPU 버스트 시간을 미리 알 수 없다는 점

2. 기아 현상(starvation) 문제

CPU 버스트가 짧은 프로세스에게만 CPU를 할당하게 되면 CPU 버스트가 긴 프로세스는 준비 큐에 서서 무한정 기다리는 문제가 발생한다. 최악의 경우 영원히 CPU를 할당 받지 못할 수도 있다. 이는 SJF의 심각한 문제점이다.

(3) 우선순위 스케줄링 [비선점][선점]

우선순위(priority) 스케줄링이란 준비 큐에서 기다리는 프로세스들 중에서 우선순위가 가장 높은 프로세스에게 제일 먼저 CPU를 할당하는 방식을 말한다. 우선순위는 우선순위값을 통해 결정되며 우선순위값이 작을수록 높은 우선순위를 가지는 것으로 가정한다.

현재 CPU에서 수행 중인 프로세스보다 우선순위가 높은 프로세스가 도착하여 CPU를 선점하게 되면 선점형 방식이 되고, 이와 달리 CPU를 자진 반납하기 까지 기다리게 되면 비선점형 방식이 된다.

우선순위 스케줄링에도 기아 현상(starvation) 문제가 발생한다. 이를 해결하기 위해 노화(aging) 기법을 사용할 수 있다. 대기 시간이 길어지는 프로세스의 우선순위를 조금씩 높여 CPU를 할당 받을 수 있게 해주는 것이다.

(4) 라운드 로빈 스케줄링 [선점]

라운드 로빈(Round Robin) 스케줄링은 시분할 시스템의 성질을 가장 잘 활용한 스케줄링 방식이다.

각 프로세스가 CPU를 연속적으로 사용할 수 있는 특정 시간인 '할당시간(time quantum)'으로 제한하고, 할당시간이 경과되면 해당 프로세스로부터 CPU를 회수해 준비 큐에 줄 서 있는 다른 프로세스에게 CPU를 할당하는 방식이다.

할당시간이 너무 짧으면 문맥교환(context switching)이 빈번하여 오버헤드가 커지고, 할당시간이 너무 길면 FCFS와 같은 결과가 나오게 된다. 즉, 적정 할당시간을 설정하는 것이 중요하다.

라운드 로빈 스케줄링은 대기 중인 모든 프로세스에게 CPU를 번갈아가며 할당할 수 있기에 대화형 프로세스의 빠른 응답시간을 보장할 수 있다는 장점이 있다.

(5) 멀티레벨 큐 [선점]

멀티레벨 큐(multi-level queue) 스케줄링은 준비 큐를 여러개로 분할해 관리하는 스케줄링 기법을 말한다.

쉽게 말하면 CPU를 사용하기 위해 한 줄서기가 아니라 여러 줄로 서는 것이다.

일반적으로 멀티레벨 큐에서는 대화형 작업을 담기 위한 전위 큐(foreground queue)와 계산 위주의 작업을 담기 위한 후위 큐(background queue)로 분할하여 운영된다.

전위 큐에서는 응답시간을 짧게 하기 위해 라운드 로빈 스케줄링을 사용하는 반면, 응답시간이 중요하지 않은 후위 큐에서는 FCFS 스케줄링 기법을 사용해 문맥교환(context switching) 오버헤드를 줄인다.

멀티레벨 큐에는 또 다른 스케줄링이 필요하다. 바로 큐 자체에 대한 스케줄링이다. 우선순위가 높은 큐를 순서대로 처리하는 고정 우선순위(fixed priority) 방식이 있으며, 기아 현상(starvation)을 해결하기 위한 타임 슬라이스(time slice) 방식도 있다. 타임 슬라이스 방식은 각 큐에 CPU 시간을 적절한 비율로 할당하는 방법이다. 예를 들어 전위큐에 80% 후위 큐에 20%를 할당해 스케줄링하는 방식이다.

(6) 멀티레벨 피드백 큐 [선점]

멀티레벨 피드백 큐(Multilevel Feedback Queue)는 여러 큐에 줄을 세운다는 측면에서 멀티레벨 큐와 유사하나, 프로세스가 하나의 큐에서 다른 큐로 이동이 가능하다는 점이 다르다.

그림에서 상위 2개의 큐는 각각 할당시간(Quantum)이 8과 16인 라운드 로빈 스케줄링을 사용한다. 세번 째 큐는 FCFS 스케줄링 기법을 사용한다.

1. 프로세스가 준비 큐에 도착하면 우선순위가 가장 높은 큐에 줄을 선다. (할당시간 8)

2. CPU 사용시간이 짧은 프로세스는 작업이 완료되고, 작업이 완료되지 않은 프로세스들은 할당시간이 16인 두번째 큐로 내려가서 줄을 선다.

3. 두번째 큐에서도 작업이 완료 되지 않으면 계산 위주의 프로세스로 간주되어 최하위 큐로 이동하고 FCFS 스케줄링을 적용 받는다.

멀티레벨 피드백 큐는 상위 큐가 비었을 때 다음 하위 큐가 CPU를 할당 받는 구조이다. 이러한 방식은 라운드 로빈 스케줄링을 발전시켜 CPU 작업시간을 다단계로 분류함으로써 작업시간이 짧은 프로세스일수록 더욱 빠른 서비스가 가능하게 되고, 작업시간이 긴 프로세스에 대해서는 문맥교환 없이 CPU 작업에만 열중할 수 있는 FCFS 방식을 사용할 수 있게 한다.

(7) 다중처리기 스케줄링

현대의 CPU는 프로세스가 여러개인 다중처리기 시스템(multi-processor system)이다. 다중처리기 환경에서의 CPU 스케줄링은 CPU가 하나인 시스템보다 복잡한 문제가 된다.

1. 준비큐에 한줄로 세워 CPU가 알아서 프로세스를 꺼내어가도록 할 수 있다. 그러나 반드시 특정 CPU에서 수행되어야 하는 프로세스가 있는 경우라면 문제가 된다.

2. 각 CPU 별로 줄 세우기를 한다. 이러한 경우 특정 CPU에만 작업이 집중되는 현상이 발생할 수 있다. 따라서 다중 처리기 스케줄링에서는 이와 같은 현상을 방지하기 위한 부하균형(load balancing) 매커니즘을 필요로 한다.

(8) 실시간 스케줄링

실시간 시스템에서는 각 작업마다 주어진 데드라인이 있어 정해진 데드라인 안에 반드시 작업을 처리해야 한다.

실시간 시스템은 데드라인(deadline)을 반드시 지켜야하는 경성 실시간 시스템과 데드라인이 존재하기는 하지만 데드라인을 지키지 못했다고 해서 위험한 상황이 발생하지는 않는 연성 실시간 시스템이 있다.

실시간 환경에서의 스케줄링은 빠른 서비스도 중요하지만 데드라인을 지키는 것이 더욱 중요하다. 따라서 데드라인이 얼마 남지 않은 요청을 먼저 처리하는 EDF(Earlist Deadline First) 스케줄링을 널리 사용하게 된다.

Post

References

KOCW [운영체제] - 반효경 교수

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[OS] 뮤텍스(Mutex) vs 세마포어(Semaphore)

장장스 — Fri, 19 Nov 2021 18:36:04 +0900

뮤텍스(Mutex)와 세마포어(Semaphore)

안녕하세요? 장장스입니다.

오늘은 기술면접에서 물어본다고 하는(?) 뮤텍스와 세마포어에 대해 정리하겠습니다.

언제 등장해?

교착상태(deadlock)에 대해 들어보셨다면 이 글을 읽을 준비가 되신겁니다. 교착상태는 제한된 자원을 두고 프로세스나 스레드가 작업을 하지 않고 무한 대기에 빠지게 되는 것을 말합니다.

교착상태가 발생하기 위해서 다음과 같은 4가지 조건이 필요합니다.

상호 배제
점유 대기
비선점
순환 대기

이 중 상호 배제 조건을 해결하기 위한 방법이 뮤텍스(Mutex)와 세마포어(Semaphore)입니다.

뮤텍스(Mutex)

뮤텍스는 mutual과 exclusion의 합성어로, 여러 스레드를 실행하는 환경에서 자원에 대한 접근에 제한을 강제하기 위한 동기화 매커니즘을 말합니다.

1. Boolean 타입의 Lock 변수를 사용하여 자원에 대한 접근을 제한합니다.

2. 임계영역(critical section)의 자원에 접근하면 해당 스레드는 Lock을 걸어버립니다. 이 때, 다른 스레드가 공유자원에 접근하면 Blocking 후 대기 큐로 보냅니다.

3. 공유자원 사용을 마친 스레드는 Lock을 해제합니다. Lock 해제는 Lock을 건 스레드만 해제할 수 있습니다.

스핀락(SpinLock)

뮤텍스와 유사한 스핀락이라는 방법도 있습니다.

1. 뮤텍스와 달리 대기 큐를 갖지 않으며 Busy-waiting 합니다.

2. Mutex-nonblocking 모델로 볼 수 있습니다.

세마포어(Semaphore)

세마포어는 변수를 통해 접근 가능한 스레드를 제한합니다. 뮤택스는 1개의 스레드만 자원을 사용할 수 있었으나 세마포어변수 만큼 공유 자원에 접근 할 수 있습니다.

1. 세마포어 변수를 통해 wait, signal을 관리합니다 세마포어 변수는 0이상의 정수 값을 갖습니다.

2. 세마포어 변수가 1개인 경우 뮤텍스 처럼 사용이 가능합니다.

3. 뮤텍스와 달리 Lock을 걸지 않은 스레드도 signal을 보내 Lock을 해제 할 수 있습니다.

Post

2021.08.16 - [OS] - [OS] 데드락 (Deadlock) - 교착상태

References

[10분 테코톡] 와일더의 Mutex vs Semaphore

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[백준] 2143 두 배열의 합 #JAVA #이분탐색

장장스 — Thu, 18 Nov 2021 20:39:09 +0900

[백준] 2143 두 배열의 합 #JAVA

코드

import java.io.*;
import java.util.*;

public class Main {

	public static void main(String[] args) throws IOException{
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

		int[] arrA, arrB;
		int[] subArrA, subArrB;
		StringTokenizer stA,stB;
		long total = 0; // 21억개를 초과하는 경우가 존재
		
		int T = Integer.parseInt(br.readLine());
		int N = Integer.parseInt(br.readLine());
		stA = new StringTokenizer(br.readLine());
		int M = Integer.parseInt(br.readLine());
		stB = new StringTokenizer(br.readLine());
		
		arrA = new int[N];
		arrB = new int[M];
				
		for (int i = 0; i < N; i++) {
			arrA[i] = Integer.parseInt(stA.nextToken());
		}
		for (int i = 0; i < M; i++) {
			arrB[i] = Integer.parseInt(stB.nextToken());
		}
		
		// 배열 A,B로 만들 수 있는 누적합 배열을 구한다.
		//배열 A로 만들 수 있는 누적합 배열 구하기
		int size = 0;
		int idx = 0;
		
		for (int i = 1; i <= N; i++) {
			size += i;
		}
		subArrA = new int[size];
		for (int i = 0; i < N; i++) {
			int sum=0;
			int at = i;
			while (at < N) {
				sum += arrA[at++];
				subArrA[idx++] = sum;
			}
		}
		
		//배열 B로 만들 수 있는 누적합 배열 구하기
		size = 0;
		idx = 0;
		for (int i = 1; i <= M; i++) {
			size += i;
		}
		subArrB = new int[size];
		for (int i = 0; i < M; i++) {
			int sum=0;
			int at = i;
			while (at < M) {
				sum += arrB[at++];
				subArrB[idx++] = sum;
			}
		}
		
		//Arrays.sort(subArrA);
		Arrays.sort(subArrB);
		

		//이분탐색
		for (int num : subArrA) {
			int tar = T - num; // 타겟 숫자
			
			//타겟 숫자의 왼쪽을 찾는다.			
			int left= lower_idx(tar ,subArrB);
            
			//타겟 숫자의 오른쪽을 찾는다.
			int right = upper_idx(tar ,subArrB);
			
			//total에 더한다.
			total +=(right - left);
			
		}
		
		System.out.println(total);
		
	}
	
	private static int lower_idx(int target, int[] arr) {
		
		int st = 0;
		int en = arr.length;
		
		while (st < en) {
			int mid = (st+en)/2;
			
			if(arr[mid] >= target) {
				en=mid;
			}else {
				st = mid+1;
			}
		}
		
		return st;
		
	}
	
	private static int upper_idx(int target, int[] arr) {
		
		int st = 0;
		int en = arr.length;
		
		while (st < en) {
			int mid = (st+en)/2;
			
			if(arr[mid] > target) {
				en=mid;
			}else {
				st = mid+1;
			}
		}
		
		return st;
	
	}
	
}

풀이

배열 A,B의 누적합 배열을 구한다. (-> subArrA, subArrB)
배열 subArrA를 for문을 돌리며 배열subArrB B = T-A 의 값이 있는지 이분탐색을 통해 확인한다.
lower_idx와, upper_idx 를 통해 타겟에 맞는 값을 찾는다.

주의 사항

정답인 total 변수는 int가 아닌 long 변수이다.
- 배열 A,B는 최대 1000개의 값으로 각각 1000!개만큼의 부 배열이 나온다. (subArrA, subArrB의 크기 500500)
- 모든 배열이 쌍 개수가 맞는다고 하면 500500 X 500500으로 int 자료형의 개수인 21억개를 넘어간다.

반례

#INPUT
5
3
1 5 3
2 
1 2

#OUTPUT
15

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[자료구조] 힙(heap) #java

장장스 — Wed, 17 Nov 2021 17:51:23 +0900

힙(heap) 자료구조

안녕하세요? 장장스입니다.

오늘은 힙자료구조에 대해 알아보겠습니다.

힙 (heap)

힙은 최댓값 및 최솟값을 찾아내는 연산을 빠르게 하기 위해 고안된 완전이진트리를 기반으로 한 자료구조입니다.

힙에는 최대 힙(max heap)과 최소 힙(min heap)이 있습니다. 부모 노드가 자식 노드보다 크면 최대 힙, 반대이면 최소 힙입니다. 가장 큰 숫자가 뿌리에 있게 하려면 최대 힙, 가장 작은 숫자로부터 시작하려면 최소 힙을 사용하면 됩니다.

최대 힙 (max heap)

max heap은 root에 가장 큰 값이 오는 heap 입니다.

최소 힙 (min heap)

min heap은 root에 가장 작은 값이 오는 heap 입니다.

힙 추가

그렇다면 새로운 데이터를 추가하거나 제거는 어떻게 될까요? max heap, min heap의 규칙을 지키야 합니다. 최대 힙이면 부모 노드가 자식 노드보다 커야 하고 최소 힙은 자식 노드가 부모 노드보다 커야 합니다.

1. 비어있는 공간에 노드를 추가합니다.
2. 부모 노드보다 큰 숫자인지 확인하고 만약 그렇다면 두 노드를 바꿉니다. (trickle up)

힙 제거

1. 루트를 제거합니다.
2. 트리의 마지막 요소를 루트에 넣어줍니다.
3. 루트에서 시작하여 두 자식 중 큰 노드와 바꿔주어 힙의 규칙을 만족하게 합니다. (trickle down)

무언가를 제거할 때 힙에서는 항상 루트를 제거해야 합니다.

Post

2021.11.16 - [DataStructures] - [자료구조] 트리(Tree)

References

[부스트코스] 자바로 구현하고 배우는 자료구조

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[자료구조] 트리(Tree)

장장스 — Tue, 16 Nov 2021 16:12:30 +0900

트리(Tree)

안녕하세요? 장장스입니다.

오늘은 Tree 자료구조에 대해 알아보겠습니다.

트리 (Tree)

가계도처럼 노드를 나무 형태로 연결한 구조를 트리라고 합니다. 트리에 있는 각각의 요소는 노드입니다. 위 사진에서처럼 노드는 부모, 자식 형태로 이어집니다.

뿌리 (root): 트리의 시작 부분입니다. 뿌리를 통해 들어가서 트리를 탐색합니다.
잎 (leaf): 자식이 딸려있지 않은 부분입니다. 노드라고 부르기도 합니다.
간선 (edge): 두 노드를 연결하는 선입니다. 뿌리로부터의 간선의 수에 따라 level을 나눕니다.

트리의 높이, 깊이, 레벨

트리 자료구조에 대해 이야기하다 보면 높이, 깊이, 레벨에 대해 언급이 됩니다. 차이점에 대해 알아봅시다

높이(height): 루트에서 가장 먼 잎(노드) 까지 거치게되는 간선 개수를 말한다.
깊이(depth): 루트에서 현재 노드 사이의 간선 개수를 말한다.
레벨(level): 트리의 깊이와 정의가 비슷하지만 그 기준이 간선이 아닌 노드의 개수이다. 따라서 $d e p t h + 1 = l e v e l$ 이 성립한다.

Post

References

[부스트코스] 자바로 구현하고 배우는 자료구조

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

[자료구조] 해시 구현하기 #java

장장스 — Tue, 5 Oct 2021 16:46:18 +0900

해시 자료구조 자바로 구현하기

Hash.java

public class Hash<K, V> implements HashInterface{

    class HashElement<K, V> implements Comparable<HashElement<K,V>>{

        K key;
        V value;

        public HashElement(K key, V value){
            this.key = key;
            this.value = value;
        }

        @Override
        public int compareTo(HashElement<K, V> o) {
            return (((Comparable<K>)this.key).compareTo(o.key));
        }
    }

    int numElements;
    int tableSize;  //array size
    double maxLoadFactor;
    LinkedList<HashElement<K,V>>[] hashArray;

    public Hash(int tableSize){
        this.tableSize = tableSize;
        hashArray = (LinkedList<HashElement<K,V>>[]) new LinkedList[tableSize];

        for (int i = 0; i < tableSize; i++) {
            hashArray[i] = new LinkedList<HashElement<K,V>>();
        }
        maxLoadFactor = 0.75;
        numElements = 0;
    }

    public double loadFactor(){
        return (double)numElements/tableSize;
    }

    public void resize(int newSize){

        LinkedList<HashElement<K,V>>[] new_array =(LinkedList<HashElement<K,V>>[]) new LinkedList[newSize];

        for (int i = 0; i < newSize; i++) {
            new_array[i] = new LinkedList<HashElement<K,V>>();

        }

        for (LinkedList<HashElement<K,V>> linkedList: hashArray) {

            for (HashElement<K,V> he :linkedList) {
                K key = he.key;
                V value = he.value;
                HashElement<K,V> new_he = new HashElement<>(key, value);
                int hashVal = (key.hashCode() & 0x7fffffff %newSize);

                new_array[hashVal].add(new_he);

            }
        }

        hashArray = new_array;
        tableSize = newSize;


    }

    public boolean add(K key, V value){

        if( loadFactor() >maxLoadFactor){
          resize(tableSize*2);
        }

        HashElement<K,V> he = new HashElement<>(key, value);

        int hashval = key.hashCode();
        hashval = hashval & 0x7fffffff;
        hashval = hashval % tableSize;

        hashArray[hashval].add(he);
        numElements++;
        return true;
    }

    public boolean remove(HashElement he){
        int hashval = he.key.hashCode();
        hashval = hashval & 0x7fffffff;
        hashval = hashval % tableSize;

        hashArray[hashval].remove(he);
        numElements--;
        return true;
    }

    public V getValue(K key){
        int hashval = key.hashCode()&0x7fffffff % tableSize;
        for (LinkedList<HashElement<K, V>> linkedList: hashArray) {

            for (HashElement<K,V> he: linkedList) {
                if( ((Comparable<K>)key).compareTo(he.key) == 0 ){
                    return he.value;
                }
            }
        }

        return null;
    }

    class IteratorHelper <T> implements Iterator<T>{

        T[] keys;
        int position;

        //constructor
        public IteratorHelper(){
            keys = (T[]) new Object[numElements];
            int p = 0;
            for (int i = 0; i < tableSize; i++) {
                LinkedList<HashElement<K,V>> list = hashArray[i];

                for (HashElement<K,V> he: list) {
                    keys[p++] = (T)he.key;
                }
            }
            position = 0;

        }

        @Override
        public boolean hasNext() {
            return position < keys.length;
        }

        @Override
        public T next() {
            if(!hasNext()){
                return null;
            }else{
                return keys[position];
            }
        }
    }

}

Git 소스 보기

Post

2021.10.01 - [DataStructures] - [자료구조] 해시(hash) #java

References

부스트코스 - 자바로 구현하고 배우는 자료구조

잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)

장장스

[JPA] No converter found capable of converting from type [org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap] to type [com.web.blog.dto.post.PostidandviewcntWrapperclass] 오류

No converter found capable of converting from type [org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap] to type [com.web.blog.dto.post.PostidandviewcntWrapperclass오류

JPQL 프로젝션에서 발생하는 문제

해결방법 (new jpql.domain.MemberDto)

[JPA] 공통 매핑 정보 @MappedSuperclass

[JPA] 공통 매핑 정보 @MappedSuperclass

실무에서 공통으로 사용되는 칼럼들

@MappedSuperclass

Post

References

[JPA] 상속관계 맵핑 @Inheritance, @DiscriminatorColumn

상속관계 맵핑 @Inheritance, @DiscriminatorColumn

상속관계 맵핑

@Inheritance

InheritanceType.JOINED 전략

InheritanceType.SINGLE_TABLE 전략

InheritanceType.TABLE_PER_CLASS 전략 (비추천)

Post

References

[JPA] 단방향 양방향 연관관계와 다중성 #다대일 #일대다 #일대일 #다대다

[JPA] 단방향 양방향 연관관계와 다중성 #다대일 #일대다 #일대일 #다대다

단방향 관계, 양방향 관계

연관 관계의 주인

연관 관계 메서드

다중성

다대일(N:1)

일대다(1:N)

일대일(1:1)

다대다(N:M)

Post

References

[JPA] 기본키(PK) 매핑 전략 IDENTITY, SEQUENCE, TABLE, AUTO

[JPA] 기본키(PK) 매핑 전략

GenerationType.IDENTITY

GenerationType.SEQUENCE

GenerationType.TABLE

GenerationType.AUTO

기본키 맵핑 어노테이션

@GeneratedValue (strategy = GenerationType.IDENTITY)

@GeneratedValue (strategy = GenerationType. SEQUENCE)

@GeneratedValue (strategy = GenerationType.TABLE)

@GeneratedValue (strategy = GenerationType.AUTO)

Post

References

[JPA] 필드와 컬럼 매핑 @Column, @Enumerated, @Temporal, @Lob

[JPA] 필드와 컬럼 매핑@Column, @Enumerated, @Temporal, @Lob, @Transient

@Column

@Temporal

@Enumerated

@Lob (BLOB, CLOB)

@Transient

Post

References

[JPA] 데이터베이스 스키마 자동 생성 옵션 (hibernate.hbm2ddl.auto)

[JPA] 데이터베이스 스키마 자동 생성 옵션 (hibernate.hbm2ddl.auto)

데이터베이스 스키마 자동 생성

스키마 자동 생성 hibernate.hbm2ddl.auto 속성

Post

References

[JPA] 영속성 컨텍스트(Persistence Context)와 주요 기능

[JPA] 영속성 컨텍스트(Persistence Context)와 주요 기능

영속성 컨텍스트(Persistence Context)란?

엔티티(Entity) 매니저

엔티티의 생명주기

1차 캐시(First Level Cache)

쓰기 지연(Write Behind)

변경 감지(Dirty Checking)

Post

References

스트림 활용하기, 중간연산과 최종연산 #filter #map #findAny #reduce

스트림 활용하기, 중간연산과 최종연산

#filter #distinct

#takeWhile #dropWhile #skip #limit

#map #flatMap

#anyMatch #allMatch #noneMatch

#findAny #findFirst

1. 스트림 요소 필터링

2. 스트림 슬라이싱

3. 스트림 요소 매핑

No converter found capable of converting from type [org.springframework.data.jpa.repository.query.AbstractJpaQuery$TupleConverter$TupleBackedMap] to type [com.web.blog.dto.post.PostidandviewcntWrapperclass
오류

[JPA] 필드와 컬럼 매핑
@Column, @Enumerated, @Temporal, @Lob, @Transient