안녕하세요!!
급히 고향으로 내려와서 바로 준비 했던 내용을 블로그를 쓴다는 점에 저를 칭찬합니다!!!
스터디원 분중 고맙게도 블로그를 체크해주시시는 스터디원 이 있습니다.
그분께 진심으로 고맙게 생각하고 있습니다. 팀원을 잘 만난거 같에요.
그럼 어제 못했던 멘토님 질문을 다시 정리 해 볼려고 합니다.
Hash Table은 왜 실무에서 잘 안쓸까?
이 질문을 받고 꽤나 당황 했던 것을 기억합니다.
그래서 다음에 꼭 답변하겠다 말하고 자료 조사를 한것을 정리하겠습니다.
- hash Map | Hash Table 의 차이점
hash Map : 키 - 값(null ) 가능
hash Table : 키-값(null) 불가능 - 스레드 안전성
hash Map : 불안정
hash Table : 안정
이 정도가 책에 정리된 내용 이었습니다.
정리한 것만 봐서는 hash Table 이 꽤나 좋은 Java Collection 인것 같았습니다.
그럼 왜 안쓰냐
public synchronized V put(K key, V value) {
// Make sure the value is not null
if (value == null) {
throw new NullPointerException();
}
// Makes sure the key is not already in the hashtable.
Entry<?,?> tab[] = table;
int hash = key.hashCode();
int index = (hash & 0x7FFFFFFF) % tab.length;
@SuppressWarnings("unchecked")
Entry<K,V> entry = (Entry<K,V>)tab[index];
for(; entry != null ; entry = entry.next) {
if ((entry.hash == hash) && entry.key.equals(key)) {
V old = entry.value;
entry.value = value;
return old;
}
}
addEntry(hash, key, value, index);
return null;
}
...출처 : https://hpotter1993.tistory.com/49
아주 좋은 블로그를 찾았습니다(물론 퇴근 30분전에 화장실에서 ^^)
??? :그래서 이게 뭔데
라고 생각하실 분들도 있습니다.
아까 위에서 Hash Table은 스레드에 안정성이 있다고 말했습니다.
그 이유가 synchronized(kotlin : @synchronized) 이지요
뭐 물론 다중 쓰레드 상황에서는 아주 좋을수 있으나 제가 현업에서 일하고 있지만
(아직 안겪어 본것일수 있습니다.)
앱에서 시작부터 끝까지 멀티 쓰레드를 쓰는 상황은 왠만해서는 잘 없습니다.
그래서 단일 스레드를 상황에서는 synchronized 로 인한 동기화 때문에 앱의 성능이 저하 될수 있다는 점에서 현업 분들이 꼭 필요할때가 아니라면 사용을 안하는거 같습니다.
스레드 풀은 무엇인가?
이 것은 제가
??? : 어? 이거 물어보실거 같은데 준비하자
했지만 안물어보셔서 억울해서 제가 글을 쓰는것입니다 .
쓰레드 풀이란? 만약 다수의 병렬 처리를 한 앱에서 한다고 가정을 해봅시다
개발자 : 이거 너무 스레드를 많이 쓰는데 앱이 버틸까?
앱 : 스레드를 생성합니다. 스케중링을 위한 메모리를 사용하겠습니다 * 100
앱 : 1 스레드 작업 처리 완료
앱 : 2 스레드 작업 처리중
스레드1 : 난 뭐해 이제...?
개발자 : 이거 cpu가 버틸까.....물론 이 가정은 너무 과장 했다고 할수 있습니다 .
현업에 가면 많은 데이터를 할때도 있지만 저정도까지는 아닐겁니다
(만약 그렇다면 그 프로젝트은 뭘까,,,,)
지속적인 메모리 사용으로 cpu의 사용으로 인하여 성능 저하로 이루어질수 있습니다 .
??? : 에이 요즘 스마트폰이 얼마나 좋은데 네 요즘 스마트폰 좋지요.
근데 pc보다 좋다고 할수 있나요?
그리고 제가 갤럭시 S 을 사용하고 있어서 괜찮다고 생각하지만
이 앱이 플레이스토어에 출시했을시 갤럭시 A 사용자가 이 앱을 다운 받는다면
앱이 죽지 않고 지속적으로 서비스 한다고 자신할수 있으신가요?
그래서 나온게 스레드 풀입니다.
개발자 : 불안하니 스레드 의 갯수를 정해놓자 , 그리고 작업 큐를 생성해서 하나씩 처리하자
그리고 작업이 끝난 스레드는 큐에서 나와 다른 작업을 들고 대기를하자
앱 : 스레드를 생성합니다 * 10 개 각 스레드는 작업을 대기중입니다 .
앱 : 처리 완료 이제 이 스레드는 다른 작업을 위해 대기 하겠습니다. 다른 작업꽤나 합리적이죠?
공장에서 A 조립 B 조립 식으로 순서대로 작업을 수행하면 어느순간 갤럭시 S 가 탄생하는 것처럼이요
풀링은 무엇인가?
멘토님 : 풀링은 뭘까요?
저 : 어......(그게 앱에서 쓰이는건가...?)대충 이랬던 상황 기억이...
책을 잘 읽었다고 생각했는데 대답을 못해서 분해서
그날 열심히 자료를 찾았던 기억이 있습니다 .
이전에 학교를 다닐떄 앱에서 실시간으로 다른 사용자가 앱에 특정 버튼을 누를시
다른 사용자의 폰에서 VIEW 가 변경되야 하는 기능 구현이 있었습니다.
바로 교수님한테 달려가서 물어봤죠
교수님 : 음 이런상황은요 두가지 해결책이 있어요. 바로 풀링 와 push 이에요
저: 오 풀링이랑 push 은 뭔가요?
교수님 : 저번시간에 알려줬잖아요!!!!
저 : 아...ㅎㅎ....풀링이란 : 서버와 앱을 연결후 일정 시간 때마다 요청을 보내 데이터를 받는 형식 입니다.
웹 , 앱 : 서버 연결 ...데이터 요청
서버 : 데이터 전송
웹 , 앱 : 데이터 수신...연결 종료
10초후
웹 , 앱 : 서버연결...데이터 요청
서버: 데이터 전송
웹 , 앱 : 데이터 수신..연결종료대충 이런식으로 무한 반복 하는 것입니다.
이렇게 하면 사용자한테는 실시간처럼 데이터를 받아 오는것처럼 보이지만
앱에게서는 10초간의 쉬는 시간이 주어지지요
단 단점은 :
- 쉬는시간을 너무 많이 주면 -> 데이터 받는 텀이 매우 느려짐
- 쉬는 시간을 짧게 주면? -> 서버쪽에서 데이터를 전송하는 주기가 매우 많아 짐으로 자칫 잘못하면 서버 과부하를 유발함
이러한 점으로 인하여 풀링 기법을 사용할려고 할시에는 앱(웹) 개발자와 벡엔드 개발자 끼리 많은 의사 소통을 해야 하겠습니다.
그림 읽어 주셔서 감사합니다
아 push가 뭔지 궁금하고 앱(aos , ios )에서 구현 해보고 싶다면
https://firebase.google.com/docs/cloud-messaging/fcm-architecture?hl=ko
읽어보시고 한번 사용을 권장 드립니다.
-비판 와 피드백은 언제나 환영입니다-
