MZ 개발자

개요Common 모듈을 구현하면서 FileProcess에 대한 정의와 어떻게 I/O처리 과정에서 Sync/Async와 Blocking/NonBlocking이 등장하게 되었는지 배경을 소개한다.기존 프로젝트에서 파일 업로드 및 파싱을 하여 변환하는 프로세스가 존재했다. 처음 구현한 방식은 MultiPartFile을 받고, LocalStorage에 파일을 쓰고, 쓴 파일을 다시 읽어 파싱한 후 파싱 결과를 DB에 저장하도록 되어있었다.동기화 문제기존 방식은 MultiPartFile → Local Save → Local Load → Parsing순서로 하나의 thread에서 요청이 들어온 순서대로 처리를 진행하였다.만약 여러 사람이 동시에 요청을 보낸다면?즉 thread 여러 개가 동시에 요청을 보낼 때 공유..

시작하기 앞서 ‘본 문서는 동시성과 관련된 용어들을 정리해 보고, 프로젝트를 진행하면서 발생했던 동시성 문제를 다양한 동시성 처리 기법들을 사용하여 해결하여 결과 비교 분석’을 위해 작성되었습니다..동시성 관련 용어병렬처리(Parallel Computing)병렬처리는 간단히 말해서 여러 명령을 같은 순간에 처리하는 것입니다. 일반적으로 하나의 CPU 코어는 한 번에 하나의 명령을 처리할 수 있습니다. 만약 하나의 프로그램에서 다중 코어를 이용해 여러 명령을 한 번에 처리한다면 병렬 처리라고 할 수 있습니다. 반드시 CPU 코어를 사용해서 병렬처리를 할 수 있는 것은 아니고, 수천 개의 코어로 이루어진 GPU를 활용하여 병렬처리를 하는 방법도 있습니다.멀티쓰레딩(Multithreading)OS가 제공하는 ..

원재가 어떤 물건을 조건 하에 사재기를 하려고 하는데 조건은 다음과 같다. 1. 원재는 연속된 N일 동안의 물건의 매매가를 예측하여 알고 있다. 2. 당국의 감시망에 걸리지 않기 위해 하루에 최대 1만큼 구입할 수 있다. 3. 판매는 얼마든지 할 수 있다. 예를들어 5일동안 물건의 매매가를 6 9 1 1 3 으로 알고있을때 조건을 만족했을때 최대로 얻을 수 있는 이득은 6을 사고 9에 팔고 1을 사고3에 팔아서 총 7만큼 최대 이익을 챙길 수 있다. 처음 문제를 보았을때 최대 이익을 얻기 위해서 우선순위 큐를 생각하였다. 하지만 이를 이용하면 인덱스의 순서가 바뀌게 되어 우선순위 큐를 관리해주어야 한다. 우선순위 큐를 이용하여 구현한 방식이다. #include #include #include #inclu..

Line에서 JPA의 Criteria API를 이용한 동적 쿼리 생성을 조금더 직관적으로 사용하기 위해 Kotlin JDSL을 개발하고 오픈소스로 전환하였습니다. Kotlin JDSL 여기를 보면 자세한 코드를 확인할 수 있습니다. GitHub - line/kotlin-jdsl: Kotlin DSL for JPA Criteria API without generated metamodel and reflection. Kotlin DSL for JPA Criteria API without generated metamodel and reflection. - GitHub - line/kotlin-jdsl: Kotlin DSL for JPA Criteria API without generated metamodel ..

이 문제는 record가 주어지고 각각을 공백으로 구분했을때 첫번째는 타입, 두번째는 유저 아이디, 세번째는 닉네임이 주어진다. 각각의 타입에 맞게 결과를 기록 및 유저 아이디를 변경 해야한다. 구현을 하기 앞서 문제 분석을 먼저 하였다. (특히 프로그래머스 문제는 문제 길이가 길고 이해 하는데 어려움이 있다.) 아이디어 문제 구현에 필요한 변수부터 생각해보자. 1. record에 포함된 내용은 각각 "타입", "유저 아이디", "닉네임"이므로 이 3개를 저장할 변수가 필요하다. 2. 결과를 저장할 배열이 필요하다. => vector answer 3. 타입에 따라 특정 유저 아이디의 닉네임을 저장할 공간이 필요하다. => map m 상태를 그냥 배열에 pair 이렇게 저장할경우 Change 타입시 모든 ..

이 문제는 정점 쌍이 주어지면 트리의 부모가 누구인지 찾는 문제이다. 문제의 예제 입력이 너무 깔끔하게 되어있어서 쉽게 생각할 수 있지만 현재 노드에서 어떤 인접리스트를 탐색해야 할지 생각이 필요한것 같다. 처음 문제를 보았을때 인접리스트를 바로 떠올리지는 않았다. 유니온-파인드인가..?? 생각을 해봤는데 아닌것 같았고.... 뭔가 다음 노드로 이동할때 마다 이동한 노드의 부모 노드를 표시해줘야 할것 같은데 한참을 생각하다가 인접리스트를 이용한 완전 탐색을 떠올렸다. 문제의 예제를 인접리스트와 그래프로 표현하면 다음과 같다. 이제 그래프 완전 탐색을 하면서 현재의 노드의 부모가 어떤건지 표현해주면 된다. 여기서 주의할 점은 단순 dfs로 문제를 풀때 이미 탐색이 끝난 노드는 재방문 하지 않돌고 visit..

지난 포스팅에서 A*, Weighted A*에 대해 설명하고 왜 경로찾는 알고리즘에서 Weighted A*가 조금더 성능이 좋은지 알아보았습니다. 사실 A*부터 weighted A* 까지 오게된 이유는 개발중인 프로젝트에서 장애물을 피하면서 특정 경유지를 필수로 지나 목적지 까지 NxN크기의 그리드에서 배관을 자동으로 설계 할수 있도록 경로를 구해야하는 이슈가 있었습니다. 일반적인 A*알고리즘을 이용하면 dijkstra 보다 큰 그리드에 대해 출발지와 목적지 사이의 경로를 빠르게 구할수 있습니다. 하지만 이 또한 그리드 크기가 커지거나 경유지가 많아질 경우 불필요한 확장을 많이 하여 탐색 속도가 저하됩니다. 기존의 A*알고리즘의 성능을 향상시키기 위해 weighted A*알고리즘을 도입하였고 휴리스틱 함..

A Star 알고리즘은 기본으로 Djikstra 알고리즘을 확장한 개념으로 다음 노드로 이동하는 과정에서 가중치가 가장 작은 노드를 우선으로 탐색하는 개념은 동일하다. 우선순위 큐에서 Top을 뽑을 때 djikstra는 시작부터 현재 노드까지 누적비용(g)가 가장 작은 노드를 우선으로 뽑는다. 하지만 A*는 현재까지 누적 비용(g)와 현재 부터 목적지 까지의 휴리스틱 비용(h)를 합쳐 가장 작은것을 우선으로 뽑는다. 이해를 돕자면 djikstra는 현재에 충실하는 반면, A*는 미래까지도 확인하여 탐색하는 노드 확장을 기하 급수적으로 줄일 수 있다. 아래 그림은 (Djikstra, A*, Weighted A*)를 사용했을때 탐색 범위이다. G 값 계산 A*의 g값을 계산하는 방법은 다양하며, 확장 방향에..

이 문제는 N개의 물건중 몇개를 골라서 그 고른 물건의 무게가 K보다 작거나 같게 하였을때 얻을수 있는 가치의 최댓값을 구하는 문제이다. 처음 문제를 보았을때 물건을 무게순으로 정렬하여 모든 케이스에 대해 전부 탐색을 할까 생각했다. 하지만 이렇게 풀었을때 O(n!)의 시간 복잡도가 나오게 된다. 예를 들어 n이 100이라고 하였을때 1개를 선택해서 그 가치가 최대가 될수 있지만 100개를 전부 선택을 해야 가치가 최대가 될수 도 있다. 따라서 각각의 경우에 최악의 경우 100,99,98...개를 선택해야하는 경우가 발생한다. 이 문제를 해결하기 위해 2차원 배열 dp[i][k]를 생성하고 i는 n개의 물건중 i번째 물건을 선택한경우, k는 무게 제한으로 1부터 k 까지 모든 경우에 dp를 채워나가면 된..

인텔리제이에서 한글 깨짐이 발생하였습니다. 검색을 해보면 다양한 해결 방법이 나오는데요. 저는 전부 해봤는데 안되더라구요... 셋팅 -> 에디터 -> 파일 인코딩 수정도 해보고, Edit Custom VM Option 도 해보고 다 해봤는데 결과는 실패 ㅠㅠ 원인 한참 원인을 찾다가 문득 생각난게 혹시 JDK 버전 문제인가...?? 저는 JDK 버전을 JDK11, JDK18 두개를 쓰고 있는데 프로젝트 셋팅할 때 높은 버전이 좋겠지 하고 JDK18을 사용하였습니다. https://bugs.eclipse.org/bugs/show_bug.cgi?id=579383 579383 – [18] encoding proeblem: utf-8 output of Java 18 not shown correctly in Co..