개발일지

1. ConcurrentHashMap을 이용한 동시성 제어ConcurrentHashMap은 자바의 동시성 제어를 지원하는 자료구조입니다. 내부적으로 세분화된 락을 이용해, 멀티스레드 환경에서 안전하게 데이터를 조작할 수 있도록 설계되었습니다.장점:빠른 읽기/쓰기 성능: 데이터는 메모리 내에 저장되며, 메모리 기반 동작이므로 읽기/쓰기 성능이 매우 우수합니다.낮은 오버헤드: 데이터 접근 시 락을 세분화(바이 락 스트라이핑)하여, 많은 스레드가 동시에 작업을 해도 병목 현상이 상대적으로 적습니다.효율적인 멀티스레드 처리: 대규모 다중 스레드 환경에서 빠르게 데이터를 처리할 수 있으며, 주로 캐시나 일시적인 데이터 저장에 유용합니다.단점:영구 저장에 부적합: 메모리 기반이기 때문에, 시스템이 종료되면 데이터가..

1. ConcurrentMap과 ConcurrentHashMap**ConcurrentMap**은 자바의 인터페이스로, 여러 스레드가 동시에 접근하는 상황에서 안전하게 데이터를 저장하거나 읽을 수 있도록 설계된 맵입니다.**ConcurrentHashMap**은 ConcurrentMap의 구현체로, HashMap과 비슷한 방식으로 데이터를 저장하지만, 스레드 안전성을 제공하기 때문에 동시성 제어가 가능합니다.즉, 여러 스레드가 동시에 리뷰 데이터를 추가하거나 읽으려고 할 때, 충돌 없이 안전하게 처리할 수 있습니다.일반적인 HashMap은 스레드 간의 동시 작업에서 문제를 일으킬 수 있지만, ConcurrentHashMap은 내부적으로 락을 효율적으로 관리하여 스레드 안전성을 보장합니다.왜 Concurren..

게임방에 참가자가 입장하는 로직에서 처음엔 이렇게 작성했었다.@MessageMapping("/game.join/{roomId}") public void joinGame(@DestinationVariable Long roomId, String participant) { try { GameRoomDto gameRoom = gameRoomService.addParticipant(roomId, participant); messagingTemplate.convertAndSend("/topic/gameRoom/" + roomId, gameRoom.getParticipants()); } catch (IllegalStateException e) { ..

그동안 참 힘든 시간을 보냈다. 이전 프로젝트에서 나때문에 일정이 늦어져서 자괴감과 무력함을 많이 느꼈다. 그래서 이번 프로젝트에서는 이 악물고 하고 있는것 같다. 우린 웹소켓을 이용한 실시간 인디언 포커게임을 구현해 보기로 했다. 일단 백엔드 각자 웹소켓을 공부해보고 오기로 하였다. 공부하던 중 각기 다른 다중 채팅방을 구현했다. 거기서 부터 자신감이 조금 붙었던것 같다. 지금은 나아가서 게임방을 거의 다 구현한 상태인것 같다. 각기 다른 유저가 로그인해도 게임방 참여&나가기 로직과 유저가 다 나가면 그 게임방이 폭파되는 로직이 작동이 잘되는것같다. 이 과정에서도 한번의 고비가 있었다. 처음엔 그냥 스프링 시큐리티와 합쳐서 AuthenticationPrincipal를 써서 로그인한 사용자의 정보를 불러..

Mybatis 마이바티스는 SQL 쿼리와 자바 객체 간의 매핑을 위한 XML 또는 어노테이션을 사용하여 데이터베이스에 접근하는 오픈 소스 프레임 워크입니다. 특징 1. 간편한 SQL 매핑: XML 또는 어노테이션을 사용하여 SQL 쿼리와 자바 객체 간의 매핑을 정의할 수 있습니다. 이를 통해 개발자는 직접 JDBC 코드를 작성하지 않고도 데이터베이스에 접근할 수 있습니다. SELECT * FROM users WHERE id=#{id} SELECT * FROM users INSERT INTO users VALUES (#{id},#{pwd},#{name},#{email},#{address},#{phone},#{gender},null,null) UPDATE users pwd=#{pwd}, name=#{name..

매주 이번주는 저번주보다 너무 힘들었다고 느껴왔는데 이번주는 그 이전과는 비교가 안되게 힘들었다. 매주매주 갱신하는 느낌이다. sql을 기본은 안다고 생각했고 마이바티스로 하면 될것이라고 생각했었는데 JPA와 manytomany등 어노테이션을 쓰니까 더욱 편했다. 역시 배울게 참 많다. mvc도 조금은 익숙해진것같다. service에서 dto를 불러와서 jpa레파지토리를 이용해서 작업하고 그걸 컨트롤러에서 맵핑한 주소로 리턴한다는 구조가 조금은 이해가 되어가고 있는듯한 느낌이다. 이제 곧 프로젝트가 시작된다. 적어도 민폐는 안되게 더 공부하러 가야겠다.

또 한주가 끝나간다. 이번주는 유독 시간이 빠르게 흐르는것 같았다. 스프링을 다시 처음부터 공부하는데 그래도 몇번의 경험이 있었기에 무난하게 해결할수 있었을줄 알았는데 자만이었고 오만이었다는걸 알게 된 한주였다... 다시 기초부터 시작하려니 뭔가 더 헷갈리는게 많지만 그건 내가 기초가 탄탄하지 않기에 그런것이라고 생각한다. 그래서인지 정신이 없고 공부해야할것들이 너무 많기에 며칠 TIL을 쓰지 못한것같다... di와 ioc에 대해 설명해 보라는 질문을 받았는데 틀린건 없지만 정리해서 대답할 필요가 있다는 답변을 받았다. 이것 역시 정확히 몰라서 정리가 안된다고 생각한다. 한주를 버텼고 다음주, 그 다음주도 버티다 보면 지금보다는 나아질것이라고 생각은 한다. 다시 스프링 공부를 하러 가야한다.

1. 스프링 컨테이너 (Spring Container): 스프링 컨테이너는 스프링에서 자바 객체들을 관리하는 공간을 말합니다. 자바 객체를 스프링에선 빈(Bean)이라고 하는데, 스프링 컨테이너에서는 이 빈의 생성부터 소멸까지를 개발자 대신 관리해주는 곳이라고 할 수 있습니다. 컨테이너는 크게 두 종류로 나눌 수 있습니다. 하나는 BeanFactory이고, 다른 하나는 ApplicationContext입니다. ApplicationContext컨테이너가 BeanFactory의 기능을 포괄하면서 추가적인 기능을 제공하기 때문에 대부분의 경우에는 ApplicationContext를 사용합니다. 스프링 컨테이너에 객체, 빈을 등록하는 이유는 스프링이 각 객체간 의존관계를 관리하도록 하는데에 큰 목적이 있습니다...

다익스트라 알고리즘 다익스트라(dijkstra) 알고리즘은 그래프에서 한 정점(노드)에서 다른 정점까지의 최단 경로를 구하는 알고리즘 중 하나이다. 이 과정에서 도착 정점 뿐만 아니라 모든 다른 정점까지 최단 경로로 방문하며 각 정점까지의 최단 경로를 모두 찾게 된다. 매번 최단 경로의 정점을 선택해 탐색을 반복하는 것이다. 동작 단계 ① 출발 노드와 도착 노드를 설정한다. ② '최단 거리 테이블'을 초기화한다. ③ 현재 위치한 노드의 인접 노드 중 방문하지 않은 노드를 구별하고, 방문하지 않은 노드 중 거리가 가장 짧은 노드를 선택한다. 그 노드를 방문 처리한다. ④ 해당 노드를 거쳐 다른 노드로 넘어가는 간선 비용(가중치)을 계산해 '최단 거리 테이블'을 업데이트한다. ⑤ ③~④의 과정을 반복한다. ..

이번주는 bfs,dfs, 힙 정렬 등 어려운 것들이 너무 많았다. 이론을 이해하는 것과 구현하는것은 별개의 문제라는걸 뼈져리게 느낀 한주였다... 그리고 어제 오늘 몸상태가 안좋아서 이틀을 그냥 날린게 너무 크게 느껴졌다. 몸 관리도 중요하다는걸 너무 체감한 한주였다... 페어 프로그래밍은 딱히 해본적이 없는것 같다. 다만 팀리뷰 시간에 팀원들과 의견을 공유하면서 코드를 수정하고 어떤 코드가 더 나은지 비교하는 시간이 엄청 도움이 되었다고 생각한다. 다른 분들이 내 코드를 짚어줄때 여러방식을 알게되었고 내가 팀원들의 코드를 짚어줄때는 뭔가 그래도 진해되어가고 있다는 느낌이 들었던것 같다. 다만 내가 도움을 주기 위해서는 더 많은 지식이 필요하기에 꾸준한 학습이 중요하다고 생각한다.