최대값 구하는 개념과 이중 while loop를 돌며 값을 채워주는 개념까지는 잘 적용하였으나 내부 while loop를 세부적으로 구현할때 문제가 생겨 다른 사람의 풀이를 참고하였다. 해당 풀이에서의 핵심은 이동을 하고 값의 유효성을 확인하는 것이 아니라 이동할 좌표가 이미 값이 채워졌는지 확인(arr[y + 1][x] or arr[y][x + 1]과 같이) 하고 0이 아닌 값으로 이미 채워져있다면 이미 해당 좌표를 들렀다는 의미이므로 해당 좌표로 이동하지 않고 내부 while loop를 break시키는게 핵심이었다. 헷갈리는 while loop + 헷갈리는 array index 문제의 조합이라 매우 헷갈렸다. while loop와 array index에 대해 좀 더 심도있게 공부해야 할 필요를 느낀다..
복잡한듯 복잡하지 않은 문제였다. 카카오 공식 풀이에서는 그리디와 투포인터 2가지 해결 방법을 제시한다. 풀이 아이디어를 얻기까지는 꽤 어려웠으나 단순하게 한쪽 큐의 전체합이 최적해가 되는지만 판별하는 그리디라는 문제라는 것을 알고나서 구현하는 것은 매우 쉬웠다. 그리디 문제인지를 알아채기는 힘들지만 찾고나면 구현하기는 쉽다는 점이 그리디 문제의 특징인 것같다. 맨 처음 풀이는 아래 코드보다 시간복잡도가 좋지않게 풀었으나 단순 순회를 여러번 반복하는 것뿐이라 통과 자체에는 문제가 생기지 않았다. import java.util.*; class Solution { //시간복잡도 nlogn 제한 int helper(LinkedList q1, LinkedList q2, long q1Sum, long q2Sum)..
Comparator를 직접 구현하여 String끼리 값을 비교할 수 있는지를 묻는 문제였다. 기본적으로 주어지는 Collections.reverseOrder()를 이용하여 내림차순을 구현하면 String은 사전순으로 정렬되게 되어있으므로 3과 30을 비교하였을때 "330"이 아닌 "303"으로 값이 나온다. 원하는 결과를 얻기 위해서는 Comparator를 직접 구현해야한다. Comparator의 compareTo a.compareTo(b)는 a의 아스키 코드 값과 b의 아스키 코드를 비교하는 메서드이다. a는 기존에 존재하던 값을 의미하고 b는 새롭게 들어오는 값을 의미한다. 이때 (a - b) > 0라면 양수가 반환되고 그 반대에는 음수가 반환, 값이 같을 때에는 0을 리턴한다. 음수거나 0일 때에는..
배치 잡을 사용해보며 해당 시간이 되면 task를 수행하는 daemon이 내부적으로 어떻게 동작하는지 궁금해졌다. infinite while loop를 돌며 cpu와 같은 리소스를 지속적으로 사용하는 것인지 아니면 다른 방법을 통해 최적화가 되어있는지 알고 싶었다. 결과적으로 말하자면 데몬의 종류는 여러 가지이며 크게 주기적으로 깨어나는 데몬(dcron)과 다음에 깨어나야할 시간을 계산 후에 sleep하는 데몬(fcron) 등이 있다. 두 종류의 데몬 모두 sleep()을 적극적으로 활용하여 cpu 사용량을 최소화시키는 최적화가 되어있었다. dcron Dillon's cron daemon, 줄여서 dcron이라 불리는 데몬은 최대 60초마다 한번씩 sleep()에서 깨어나 .crontab으로 구현된 cr..
중복을 허용하지 않는 조합을 만들줄 아는지에 대해 묻는 질문이었다. 원하는 개수에 도달했는지 확인하는 int depth 변수 하나와 dfs 내에서 for loop의 현재 인덱스를 저장하는 int index 변수 2가지를 선언하여 각각 관리하는 것이 조합을 만드는 방법이었으나 본인의 경우 index와 depth를 하나의 변수로 처리하려고 하여 주어진 케이스만 맞고 내부 테스트 케이스가 대부분 틀리는 결과가 나왔다. String을 Alphabetic으로 관리하고자 하면 TreeSet을 이용하기. String 내의 char를 Alphabetic으로 정렬하려면 char[] -> sort -> 변수 초기화. import java.util.*; class Solution { //course를 돌면서 number마다..
다리의 길이만큼 0 (큐에 들어갈 수 없는 어떤 값)을 큐에 추가하여 다리를 구현하고 매초마다 큐에서 remove와 add를 해주면서 weight와 index를 관리해준다. 해당 '초'에 다리에서 트럭이 내려가면(remove 값이 0이 아니면) 새로운 트럭이 올라올 수 있으므로 weight 측정을 가장 먼저 구현해야 한다. 해당 문제는 시간이라는 축을 값으로 구현한다는 아이디어만 생각하면 쉬운 문제이지만 이 아이디어를 얻기가 쉽지 않아 고려해야 될 것이 엄청 많게 느껴진다. import java.util.*; class Solution { public int solution(int bridge_length, int weight, int[] truck_weights) { int answer = 0; //다..
정규표현식은 주어진 String에서 주어진 패턴에 맞는 캐릭터만 골라내는 검색 엔진이라 표현할 수 있다. 이때 정규표현식의 내부는 유한 오토마타로 구현되어있다. 내부 동작 먼저 정규표현식은 내부적으로 언어마다의 세부적인 문법 차이를 제외하고 대부분 비슷하게 구현되어있다. 패턴과 String이 주어지고 String의 왼쪽부터 시작하여 오른쪽 방향으로 비교를 시작한다. 이때 String을 한 번에 캐릭터 하나씩 파싱하여 패턴과 비교하는데 이때 패턴에서도 왼쪽-오른쪽 방향으로 비교를 하며 나아간다. String의 인풋과 String의 패턴을 비교한다고 가정해보자. 먼저 String 첫번째 캐릭터와 패턴의 첫번째 캐릭터가 일치하면 두번째 캐릭터끼리 비교한다. 두번째 캐릭터가 일치하면 똑같은 비교가 쭉 이어지고 ..
본 게시물은 해당 블로그에서 레퍼런스를 번역한 자료임을 알립니다. 퍼가실때 해당 블로그의 주소는 밝히실 필요가 없으나 레퍼런스의 주소는 밝혀주시면 감사하겠습니다. 자바 9 버전 이후부터 G1 GC가 디폴트 GC로 설정되었다. (역주: 자바 8까지는 패러렐 GC가 디폴트였고 자바 18인 현재까지 G1 GC가 디폴트 GC로 사용된다. 만약 싱글 코어라면 시리얼 GC가 디폴트로 설정된다.) G1 GC는 자바 7에 처음 도입되어 다른 GC와는 다른 매우 큰 힙 영역을 효과적이면서 동시에 다루는데에 특화되어 있다. 또한 최대 중단 시간을 넘지 않도록 설정할 수 있다. G1 GC가 다른 GC와 어떻게 다르게 동작하는지 확인하고 또 어떻게 G1 GC가 어떻게 큰 크기의 힙 영역을 다룰 때 다른 GC를 압도하는지 알아..
본 게시물은 해당 블로그에서 레퍼런스를 번역한 자료임을 알립니다. 퍼가실때 해당 블로그의 주소는 밝히실 필요가 없으나 레퍼런스의 주소는 밝혀주시면 감사하겠습니다. 자바의 GC를 이용한 메모리 관리는 해당 언어가 이륙한 엄청난 성과 중 하나라 할 수 있다. GC는 개발자로 하여금 메모리 할당과 할당 해제를 걱정할 필요없이 새로운 객체를 생성할 수 있게 해주었는데, 이는 GC가 자동으로 메모리를 다시 회수해주기 때문이다. 메모리 누수와 다른 메모리 관련된 문제를 전혀 걱정할 필요없이 더 적은 보일러플레이트 코드를 작성하게 함으로써 더 빠른 개발을 가능하게 하였다. (이론적으로는) 아이러니하게도 자바의 GC가 일을 "너무" 잘 하는 바람에, 너무 많은 객체를 생성하고 제거한다. 덕분에 대부분의 메모리 관련 문..
기본적인 개념 모든 I/O (File, Network, etc.)는 커널 레벨에서 관리된다. 애플리케이션 레벨에서 직접 I/O를 할 수 없고 모든 I/O는 커널에 System call하여 요청을 하고 그에 따른 응답을 받는 구조로 구성되어 있다는 뜻이다. 이때 애플리케이션과 커널이 소통하는 방식을 정함에 있어 블로킹과 논블로킹, 동기와 비동기로 나뉘게 된다. 애플리케이션에서 커널의 응답을 기다리면 블로킹, 기다리지 않고 다른 작업을 진행하면 논블로킹 작업의 순서를 애플리케이션에서 결정하여 순서가 보장되면 동기, 커널에서 결정하고 애플리케이션에 작업의 완료를 통보하면 비동기이다. 위에 따르면 총 4개의 경우의 수가 나오며 블로킹-비동기, 논블로킹-동기에 대한 예시(polling)가 있긴 하지만 블로킹/동기..
- Total
- Today
- Yesterday
- JavaScript
- 도커
- 레디스
- RequestParam
- Dap
- ModelAttribute
- IDE
- 아키텍처
- 루나빔
- vim
- RequestPart
- lunarvim
- RequestBody
- 배포
- neovim
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |