모르면 안 되는 10개의 자바 거짓말
1. System.exit(0)는finally 블록의 실행을 건너뜁니다.
System.setSecurityManager(new SecurityManager() {
@Override
public void checkExit(int status) {
throw new ThreadDeath();
}
});
try {
System.exit(0);
} finally {
System.out.println("In the finally block");
}
이 코드는 왜 Finally block에서 출력됩니까?왜 창고 추적 정보를 출력하지 않았습니까? 2. String str = “Hello”;그중str는 문자열 대상입니다
C++와 달리 Java의 변수는 기본 유형이거나 참조입니다.변수가 객체일 수 없습니다.이것은 다음과 같은 표현식을 의미합니다.
String str = "Hello";
String text = "Bye";
str == text; // ,
str = text; // text str
대부분의 경우 사실 큰 차이가 없지만, 이렇게 쓰면 곤혹을 일으키기 쉽다.
final StringBuilder sb = new StringBuidler();
sb.append("Hello"); // final , 。
method(sb); // ,
3. Java의 메모리 유출은 C++ 프로그래머가 이해하는 것과 같다메모리 유출은 위키백과에서 컴퓨터 과학에서 프로그램이 메모리 분배를 정확하게 관리하지 않으면 메모리 유출이 발생한다고 정의했다.대상 프로그래밍에서 메모리에 있는 대상이 코드에 접근할 수 없으면 메모리 유출입니다."그러나 자바에서는 항상 대상이 도달할 수 있으며, 강제 인용이 없는 대상은 삭제됩니다.메모리 유출이라는 용어는 자바에서 메모리에 존재하지 말아야 할 대상이 존재하고 통상적으로 사용하지 않는 자원이 집합에 저장된다는 것을 의미한다.
4. 다중 루틴 프로그래밍은 어렵다
만약 네가 경험이 없다면, 다중 프로그래밍은 확실히 매우 어렵다.만약 네가 단지 코드 한 무더기를 한 무더기의 라인에 던져 실행했을 뿐이라면, 그렇게 문제가 생기면 근본적으로 해결할 수 없고, 단지 엉망진창일 뿐이다.그러나 만약에 당신이 라인의 수요에 따라 분배를 하고 라인 간의 상호작용을 제어하며 일부 팀의 구성원들도 이해할 수 있는 간단한 모델을 사용할 수 있다면 문제는 훨씬 간단해진다.물론 또 하나의 도전은 팀의 모든 사람들이 당신의 규칙을 따르도록 해야 한다는 것이다
5. 서로 다른 조작 간의 성능에 관심을 갖지 않아도 된다
최근에 듣자니 정수의 추가, 메모리 접근, 모델링, 컨트롤러로 출력하는 문제가 있다고 한다.비록 이런 조작에서 하나하나가 앞의 것보다 수량급이 느리지만, 이 형들은 이 중에서 가장 빠른 조작, 덧셈을 최적화하고 싶어서 더 비싼 조작으로 그것을 교체했다.만약 당신이 정말로 성능을 최적화하고 싶다면, 비싼 조작을 값싼 조작으로 바꾸는 것이 가장 좋다. 만약 당신의 병목이 하드웨어에 있다면, 예를 들어 하드디스크에서 대량의 파일을 읽으려고 한다면, 소프트웨어의 코드를 수정하는 것은 아무 소용이 없다. 왜냐하면 문제는 근본적으로 여기에 없기 때문이다.
6. 랜덤 수는 모두 랜덤이다
한 조의 특정한 무작위 수는 마치 어떤 패턴의 숫자와 같다.이 문제는 내가 이 문장에서 이미 이야기한 적이 있다.많은 사람들이 랜덤 생성기가 생성하는 숫자가 사실 랜덤이 아니라고 믿지 않는다.
7. 랜덤 오류가 발생할 수 있기 때문에 가능한 한 부동 소수점 사용을 피해야 한다
같은 조작에 있어서 부동점수는 매번 같은 오류가 발생한다.잘못은 예측할 수 있기 때문에 통제할 수 있다.만약 당신이 해야 할 일이 무엇인지 잘 알고 간단한 규칙을 계속 사용한다면, 예를 들어 결과에 대한 반올림 조작을 한다면, 부동점수의 오류는 BigDecimal보다 많지 않을 것이다. 그 외에 그것의 가독성이 더욱 강하고, 효율이 100배 이상 빨라질 것이다. (동시에 발생하는 쓰레기 대상도 더욱 적다.)
8. 시구는 영원히 변하지 않는다
이 오해가 있는 것은 시간의 변화에 따라 시간대가 바뀌기 때문이다.이것은 유럽/런던이 신기원에 있을 때 1970/1/101:00이 아니라 00:00이었다는 것을 의미한다. 왜?런던은 1968년부터 1971년까지 2년 동안 여름철을 사용했기 때문이다.
지난 몇 년 동안 아직도 적지 않은 시간대에도 변화가 생겼다.모스크바는 이전에 동3구(GMT+3)였으나 지금은 동4구(GMT+4)(2011년 3월 27일부터)이다.만약 네가 2010년의 시간을 본다면, 너는 그것이 동쪽 3구이지 동쪽 4구가 아니라는 것을 발견할 것이다.
또 어떤 일들은 네가 듣기에 아마도 매우 의외라고 느낄 것이다.
1721년 스웨덴의 2월은 30일이었다.
1751년 잉글랜드의 첫날은 3월 25일로 프랑스와 비교해 11일 차이가 났다.
미국은 달력을 채택한 후 백 년을 거슬러 올라갔다. 이렇게 하면 원래 기록된 날짜들은 모두 두 가지 달력으로 표시할 수 있다.예를 들어 조지 워싱턴의 생일은 1731년 2월 11일에서 1732년 2월 22일로 바뀌었다.
9. 라인에서 비Volatile 변수를 읽을 때, 업데이트된 값을 읽을 수 있습니다.
며칠 전에 이 문제가 Stack Overflow에서 두 번 나왔습니다.일반적으로 JIT 컴파일러는 코드를 최적화할 때 이 스레드가 수정되지 않은 비volatile 형식의 필드를 내통합니다.이 코드가 컴파일되면 (당신은 - XX: + PrintCompilation을 통해 볼 수 있습니다), 다른 라인에서 이 필드를 수정하면 영원히 볼 수 없을 것입니다.게다가 무작위 동기화 블록이나 인쇄 문장은 이 최적화의 실행을 늦추거나 JIT 컴파일러를 교란하여 이 최적화를 실행하지 못하게 할 수 있다.
10. 자바 면접 문제 모두 정답
많은 자바 면접 문제가 유행이 지났거나(10년이 넘도록 업데이트되지 않았고 현재의 자바 버전과 맞지 않았거나), 여러분을 오도하거나 틀렸을 수도 있습니다.불행하게도 이 답안들은 검사도 없이 여기저기 퍼졌다.
저는 Stackoverflow의 답안을 참고하겠습니다. 왜냐하면 이곳의 답안은 동업자 심사가 더 잘하기 때문입니다.전반적으로 말하면 로즈 인디아 같은 사이트는 올라가지 마라. 위의 답안의 질이 엉망이다.만약 네가 꼬치꼬치 캐묻는 것을 좋아한다면, 위의 문장에 몇 개의 맞춤법 오류(유명 및 전문 용어)나 잘못된 말이 있는지 볼 수 있다.이런 문제들이 존재하는 한 가지 원인은 이러한 오류를 바로잡을 효과적인 피드백 메커니즘이 없기 때문이다.
Java 면접 문제 추천:
가장 가치 있는 50가지 자바 면접 문제는 입사 자바 프로그래머에게 적용된다
10가지 Java main 방법 면접 문제
Java에서 가장 흔히 볼 수 있는 10가지 면접 문제 탐구(초경전)
Java 프로그래머를 위한 10가지 XML 면접 문제
이상은 본문의 전체 내용입니다. 여러분의 학습에 도움이 되고 저희를 많이 응원해 주십시오.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
38. Java의 Leetcode 솔루션텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.