자린이 개발 공간 자린이 개발 공간

자바 쓰레드(Thread) 사용 1. 기본 개념멀티유저 지원:서버는 동시에 여러 사용자가 접속 가능한 구조.자바는 운영체제의 쓰레드를 활용하여 다중 접속을 지원.문제점:요청마다 새로운 쓰레드를 생성하면 운영체제 자원이 고갈될 위험.동시 접속 사용자가 많아지면 서버 다운 가능성 증가. 2. Thread Per Request Model - API 요청 방식정의:요청(Request)마다 하나의 쓰레드를 생성하여 처리하는 방식.Request와 Thread가 1:1 매칭.문제점:쓰레드 생성 소요 시간 → 요청 처리 지연.요청 증가 → 쓰레드 수 증가 → 과도한 Context Switching 발생.CPU 오버헤드 증가 및 CPU 시간 낭비.메모리 고갈 및 서버 응답 불가 상태 초래.위와 같은 문제를 해결하기 위해..

public void add(int index, Object data) { // TODO : 노드의 순서를 기준으로 해당 index에 삽입한다. Node node = new Node(); node.data = data; if (0 == index) { // TODO : 맨 앞에 노드를 삽입하는 경우 node.next = head; head = node; } else { // TODO : 해당 index에 삽입하려면 이전 노드를 찾아야 한다. Node foundNode = findNode(index - 1); node.next = foundNode.next; foundNode.next = node; } ++size; }​ class SinglyLinkedList { Node head = null; int ..

1. 책을 사게 된 계기이 책을 사게 된 계기는 너무 간단했다. 책 제목이 너무 재밌어 보이는 책이었다.머리말 정도는 읽어보며 책을 살까 고민을 하는데..이 책은 뭐 그런 것도 전혀 없이 그냥 책 제목만 보고 질러버렸다. ㅎㅎ2. 간단 요약처음엔.. 세상은 제정신으로 살기 힘들다와 같은 세상 이야기를 하는 책이지 않을까 하며 펼쳤는데..이 책의 핵심은 제정신이라는 단어가 아니라 '착각'이라는 단어가 핵심이라는것을 머리말을 보며 깨달았다.이 책의 내용은 왜 우리는 착각 속에 살아가는가.. 에 대한 답을 하는 책이다.단순한 착각을 넘어 조현병이 발생하는 원인에 대해서 근본적인 질문과 해답을 찾아보는 책이다.저자는 이 책에서 인간의 '확신'이 그 원인이라고 이야기를 한다. 그렇다면 [인간의 비합리적인 확신의 ..

1. 자료구조의 분류단순구조:단순히 데이터를 저장하고 관리.비단순구조:데이터 간의 관계를 표현하며, 선형구조와 비선형구조로 나뉨.선형구조: 데이터가 순차적으로 나열되는 구조예시 : 배열, 연결리스트. 스택, 큐, 덱(DQueue), 비선형 구조: 데이터가 순차적으로 나열되지 않는 구조예시 : 트리, 그래프, 집합, 해시맵, 해시테이블,  2. 배열 (Array)2.1 배열의 정의와 특징정의:동일한 데이터 타입의 데이터를 연속적인 메모리에 저장.물리적 순서와 논리적 순서가 동일.2.2 배열의 장점빠른 접근:데이터의 위치를 알고 있다면, 인덱스를 통해 즉시 접근 가능 (시간복잡도: O(1))2.3 배열의 단점삽입과 삭제 속도 저하:데이터 삽입/삭제 시, 배열을 재생성하고 데이터를 복사해야 함.시간 소요가 크..

0. 데이터와 정보 - 자료구조를 배우기 앞서 자료구조의 재료가 되는 데이터와 정보에 개념을 알아야 한다. 데이터란 무엇인가? 데이터의 사전적 정의를 검색 플랫폼별 검색을 해보았다. 네이버 : 이론을 세우는 데 기초가 되는 사실. 또는 바탕이 되는 자료. 위키백과: 문자, 숫자, 소리, 그림, 영상등의 형태로 된 의미 단위이다. 연구나 조사 등의 바탕이 되는 재료 옥스포드 사전 : 프로그램을 운용할 수 있는 형태로 기호화 한 자료 ChatGPT : 정보의 표현이나 기록된 사실, 숫자, 문자 또는 다른 기호로 표현된 모든 형태의 자료를 의미. 또 다른 사전 : 어떤 값을 포함하고 있는 가공되지 않은 1차 자료 위 정의들을 종합해보면, 결과적으로 데이터란 어떤 대상의 원천이 되는 가공되지 않은 자료라는 것으..

📌 배경요즘 직장생활을 하며 스스로를 돌아보면, 개발자라기보다는 코더에 더 가까웠다.대학생 때부터 **"개발자는 코딩만 잘하면 된다"**는 생각으로 살았고,"정해진 기능만 동작하면 됐지 뭐..." 이런 태도로 계속 일을 해왔다.업무 지시나 API 문서를 보면서도 대충 이해했다고 착각하고 개발에 착수하곤 했는데,그 결과 오류 점검 부족이나 의사소통 문제 때문에 테스트 단계에서 문제가 계속 생기기도 하였다.또한 실수가 정말 많았다.프로젝트 배포 실수Git Commit 실수프로젝트 설정 값 오류 등등...기능 중심으로만 개발을 하니, 다양한 이슈가 발생하였고, 결국 처리는 고급 개발자들의 몫이 되기 일쑤였다.그때마다 부족함을 진짜 많이 느끼긴 했지만, 그것도 그때 뿐, 놀고 자전거만 타며 허송세월을 보냈다...