가비지 컬렉션은 더 이상 사용되지 않는 메모리를 자동으로 찾아내어 해제하는 메모리 관리 메커니즘이다. Java 개발에서 가장 중요한 특징 중 하나로, 개발자가 메모리 관리에 대한 부담을 덜 수 있게 해준다. 가비지(Garbage)란?프로그램을 개발하고 실행하는 과정에서는 더 이상 사용되지 않는 메모리인 '가비지(Garbage)'가 발생한다. 이는 다음과 같은 경우에 발생할 수 있다.// 1. 객체의 참조가 null이 되는 경우String text = "Hello";text = null; // 이전의 "Hello" 객체는 가비지가 됨// 2. 객체의 참조 범위를 벗어나는 경우public void createObject() { String localVar = "Hello"; // 메서드 종료 시 접..

Volatile'Java 변수를 main memory에 저장하겠다' 라는 것을 명시하는 것매번 변수의 값을 read할 때 마다 cpu cache에 저장된 값이 아닌 메인 메모리에서 읽는 것변수의 값을 write할 때 마다 main memory에 까지 작성하는 것volatile 변수를 사용하고 있지 않는 멀티스레드 어플리케이션에서는 task를 수행하는 동안 성능 향상을 위해 메인 메모리에서 읽은 변수 값을 cpu cache에 저장하게 된다.  ExamplesharedObject를 공유하는 두 개의 스레드가 있다.스레드 1은 카운터 값을 더하고 읽는 연산을 한다. (read & write)스레드 2는 카운터 값을 읽기만 한다. (only read)public class SharedObject { public..

폴링특정 주기마다 스레드를 돌면서 시그널이 들어왔는지 확인하는 방식이다. (소프트웨어적으로 시그널을 확인하는 것) 이렇게 특정 주기마다 계속 확인해야 하기 때문에 시스템의 리소스를 많이 먹는다는 단점이 있다. 인터럽트프로그램 실행 도중에 예기치 않은 상황이 발생할 경우 현재 실행 중인 작업을 즉시 중단하고, 발생된 상황에 대한 우선 처리가 필요함을 CPU에게 알리는 것 (하드웨어적으로 시그널을 확인하는 것) 시그널이 들어온 정확한 타이밍을 알 수 있고, 반응 시간이 빠르며 시스템 부하가 적다.  인터럽트 처리 과정프로그램 실행 -> 인터럽트 요청 -> 프로그램 중단(수행중인 명령을 완료하고 PC, SR 저장) -> ISR 처리(인터럽트 벡터를 통하여 주소 접근) -> 프로그램 재시작(PC를 통해 접근) ..

시스템 콜이 무엇인가?시스템 콜은 응용 프로그램이 직접적으로접근하지 못하는 하드웨어 자원에 접근하기 위해 사용되는 인터페이스이다. 즉, 시스템 콜을 호출함으로서 해당 자원에 간접적으로 접근하게 된다.    우리가 사용하는 시스템 콜 예시와 동작 과정python의 import sys, time도 시스템 콜이고, 대표적으로 file I/O의 open, read, write 등이 있다. 한 파일에서 다른 파일로 데이터를 복사하는 프로그램을 예로 들어서 시스템 콜이 동작하는 과정을 살펴 본다.  시스템 콜 예시1. 아래 명령어와 같이, 복사할 input 파일과 output 파일의 이름을 작성한다.$ cp input.txt output.txt 2. 프로그램은 input 파일을 open(system call)하고,..

이번 시간에는 스프링과 스프링 부트가 무엇이며, 스프링 부트는 어떻게 동작하는 지에 대한 공부를 해보겠습니다.스프링 부트의 기본 의존성 중 하나인 spring-boot-starter-web 모듈을 사용하면, 기본적으로 내장 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작합니다. 클라이언트의 요청이 들어오면 서블릿이 이를 처리해야 하는데, 서블릿은 서블릿 컨테이너에서 관리하고, 톰캣이 서블릿 컨테이너의 역할과 WAS 역할을 담당합니다. 서블릿(Servlet)클라이언트의 요청을 처리하고, 결과를 반환하는 자바의 웹 프로그래밍 기술입니다. 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리합니다. 서블릿 객체는 싱글톤 패턴으로 관리되며, 멀티 스레딩을 지원합니다.   DispatcherServl..

리펙토링 중인 프로젝트의 엔티티에는 챌린지 startedDate, completedDate 컬럼이 존재하는데, 해당 컬럼의 타입은 LocalDateTime이었다. 해당 데이터를 직렬화하고 Redis에 저장한 후, 캐시 데이터를 조회할 때 역직렬화 과정을 거쳐야하는데 Jackson 라이브러리에서 LocalDate, LocalTime, LocalDateTime을 지원하지 않았다. 이를 처리하도록 사용하려면 com.fastxml.jackson.datatype:jsr310 모듈을 추가해야한다는 경고가 나타났고, 아래와 같이 추가해주었다. 그러나, 문제는 해결되지 않았다. Jackson을 공부하면서 ObjectMapper에 대한 이해가 필요함을 느꼈다. implementation 'com.fasterxml.jac..

두둥.. 에러가 발생했습니다. 발생한 이유는 org.springframework.data.domain.PageImpl 객체를 JSON으로 직렬화하거나 역직렬화하는 과정에서 발생하는 문제였습니다. 특히, Spring에서 캐싱된 Page 객체를 다시 사용할 때 나타나는 문제로, PageImpl 클래스가 기본 생성자나 적절한 생성자를 제공하지 않아 Jackson이 객체를 역직렬화할 수 없기 때문이었습니다.  Page 인터페이스를 구현한 PageImpl 클래스는 기본 생성자가 없으며, Jackson이나 다른 JSON 라이브러리가 객체를 역직렬화할 때 기본 생성자가 필요했고, 이 경우 캐시에서 꺼낸 데이터가 역직렬화되지 않으면서 예외가 발생한 것이었습니다. PageImpl의 기본 생성자도 신경써줘야 하다니 !! ..

보호되어 있는 글입니다.

docker 명령어로 redis.conf 파일을 설정하던 중 발생한 오류였다. 내가 작성한 명령어는 아래와 같았다.docker run --name redis-serer -p 6379:6379 -d -v redis-volume:/data -v ~/redis.conf:/etc/redis/redis.conf redis redis-server /etc/redis/redis.confdocker run : 도커 컨테이너 실행  --name redis-serer : 컨테이너 이름을 redis-server로 지정 -p 6379:6379 : 호스트 포트 6379, 컨테이너 포트 6379 (이 설정을 통해 호스트 머신에서 localhost:6379로 접근하면 컨테이너 내부의 redis 서버에 연결할 수 있다.) -d : ..

CORS란Cross-Origin Resource Sharing으로 교차 출처 리소스 공유라는 뜻이다. 다른 출처에서 리소스를 요청할 때 지켜야하는 정책이다. 여기서 출처(Origin)은 protocol, host, port까지 의미한다.  CORS HTTP 요청 방식단순 요청을 보내는 것(Simple Request)예비 요청을 보내서 확인 후 보내는 것(Preflight)인증된 요청을 사용하는 방식(Credential Request) Simple Request예비요청없이 서버에 바로 요청을 보내는 방법이다. 서버에 바로 본요청을 보낸 뒤, 서버는 헤더에 ACCESS-CONTROL-ALLOW-ORIGIN 값 등을 붙혀서 보내주면 브라우저가 CORS 정책 위반 여부를 검사한다.조건GET, POST, HEAD..

CSRF공격 시나리오  1. 사용자가 google.com에 로그인사용자는 google.com에 로그인하여 세션 쿠키를 받습니다. 이 쿠키는 사용자가 google.com에 다시 요청을 보낼 때마다 자동으로 포함됩니다.2. 악의적인 사이트 방문사용자는 이메일 링크, 소셜 미디어 링크 또는 광고 등을 통해 attack.com이라는 악의적인 사이트를 방문합니다.attack.com에는 CSRF 공격을 수행하기 위한 악의적인 스크립트가 포함되어 있습니다.3. 악의적인 요청 생성attack.com의 페이지에 다음과 같은 HTML 코드가 포함되어 있다고 가정합니다." style="display:none">이 코드는 이미지 태그를 사용하여 google.com으로 GET 요청을 보냅니다. style="display:non..

퍼사드 패턴을 도입하게 된 배경디자이너, 프론트엔드, 백엔드 총 5명으로 구성된 우리 팀은 올해 초부터 쉴 틈 없이 달려왔다. 매주 팀 회의, 파트별 회의, 프론트/백엔드 회의를 각각 1회씩 진행하며, 기획부터 설계, 개발까지 모두 경험했다. 배포 전에는 통합 테스트를 거쳐 최종적으로 이슈를 해결하고 도메인 등록과 배포를 통해 프로젝트를 성공적으로 마무리하였다. 프로젝트가 종료된 후 일부 팀원은 각자의 삶으로 돌아갔다. 어쩌면 당연한 일이지만, 시작이 있으면 끝이 있다는 게 시원섭섭하다. 알면서도 어쩔 수 없는 감정인 듯하다.배포된 서비스를 사용해보고 프로젝트 코드를 살펴보니 일정에 맞추느라 신경 쓰지 못했던 부분, 아쉬웠던 부분, 개선해 보면 좋을 것 같은 부분들이 보였다. 그중에서도 눈에 띈 부분은 ..