以下的这些都算是比較高级的问题了。面试中一般也非常少问到。由于它们可能会把面试者拒之门外。只是你能够自己找个时间来实践一下。
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"); }
|
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" ) ; } |
这段代码为什么会输出In the finally block？为什么没有打印出堆栈跟踪信息呢？ 2. String str = “Hello”;当中str是一个字符串对象 跟C++不同的是，Java里的变量要么是基础类型，要么是引用。变量不可能是对象。这意味着像这种表达式：
String str = "Hello"; String text = "Bye"; str == text; // 比較两个引用。而不是内容 str = text; // 把text的引用赋值给str
|
String str = "Hello" ; String text = "Bye" ; str == text ; // 比較两个引用，而不是内容 str = text ; // 把text的引用赋值给str |
大多数情况下事实上没有太大的差别，只是这么写easy引起困惑。
final StringBuilder sb = new StringBuidler(); sb.append("Hello"); // 这个引用是final类型的，而不是这个实例。 method(sb); // 能够通过方法来改动这个实例。只是这个变量是无法改动的
|
final StringBuilder sb = new StringBuidler ( ) ; sb . append ( "Hello" ) ; // 这个引用是final类型的。而不是这个实例。 method ( sb ) ; // 能够通过方法来改动这个实例，只是这个变量是无法改动的 |
- Java的内存泄露跟C++程序猿理解的一样 内存泄露在维基百科上的定义是”在计算机科学中，假设程序没有正确地管理好内存分配 ，就会出现内存泄露。在面向对象编程中，假设内存中的一个对象无法在代码中訪问不到的话。这就是内存泄露。” 只是在Java中，对象总是可达的，那些没有强引用的对象会被清除掉。
内存泄露这个术语在Java中意味着：内存中存在着不该存在的对象，通常来说是有些不再使用的资源却仍存储在集合中。
- 多线程编程非常难 假设你没有经验的话。多线程编程的确非常难。假设你仅仅是把一堆代码扔到一堆线程中去运行，那样出了问题根本没法解决，仅仅能是一团糟。 但假设你能进行线程的按需分配。控制线程间的交互。使用一些团队中的成员也能明确的简单的模式，问题就变得简单多了。当然另一个挑战就是你得让团队中的全部人都遵循你的这个规则:-)
- 不用关心不同操作间性能的不同 近期听说有个问题，它涉及到了整数的相加，内存訪问。取模，以及输出到控制台。
虽然在这些操作里面，每个都比前面一个要慢一个数量级，但这哥们就是想优化这里面最快的操作，加法，还用了些更昂贵的操作来替换它。 假设你真的想要优化性能，你最好用一个便宜的操作来替换掉那些昂贵的操作，假设你的瓶颈在硬件这块，例如说要从硬盘里面读取大量的文件。改动软件的代码是没啥用了，由于问题根本 就不在这。
- 随机数都是随机的
一组特定的随机数就像是某种模式的数字。这个问题我在 这篇文章 中已经讲到过了。
非常多人都不相信随机数生成器生成的数字事实上是不随机的。
- 应该尽量避免使用浮点数，由于它们会产生随机错误
对于同一个操作而言。浮点数每次都会产生相同的错误。错误是可预測的，因此也是可控的。假设你清楚你要做的事情是什么，并且坚持使用一些简单的规则，比方说对结果进行舍入操作。那么浮点数出的错也不会比BigDecimal要多。除此之外它的可读性更强，并且效率快了百倍以上（同一时候产生的垃圾对象也更少了）。
- 时区是永恒不变的
之所以会有这个误解是由于，随着时间的变化，时区是在改变的。这意味着欧洲/伦敦在新纪元的时候是1970/1/1 01:00而不是00:00，为什么？由于伦敦在1968年到1971年这两年间的时间内使用的是夏令时。
在过去的这些年里面，还有不少时区也发生了变化。莫斯科曾经是东三区（GMT+3），如今是东四区（GMT+4）（从2011年3月27日開始）。
假设你看下2010年的时间，你会发现它是东三区而不是东四区。
还有些事你听起来也许会感觉非常意外：
- 1721年的瑞典的2月有30天。
- 1751年英格兰的第一天是3月25日，和法国相比差了11天。
- 美国採用公历纪年后。它往前追溯了上百年，这样原先记录的那些日期都能够用两种日历来进行表示（通常为了更精确会同一时候提供两个日期）。
比方乔治华盛顿的生日从1731年2月11变成了1732年2月22。
- 当你在线程中读取一个非volatile变量时，你终于能读取它更新的那个值。
前几天这个问题在StackOverflow上出现过两回了。一般来说，JIT编译器优化代码的时候会将这个线程没有改动到的非volatile类型的字段进行内联。
一旦这个代码被编译了（你能够通过-XX:+PrintCompilation看到），你在还有一个线程对这个字段进行的改动它非常可能就永远也看不到了。
加上随机的同步块或者打印语句能够推迟这个优化的运行，或者扰乱JIT编译器。让它不去运行这个优化。
- Java面试题都是正确的
有非常多Java面试题要么是过时了（超过10年没有更新了，和如今的Java版本号已经脱节），要么是误导大家的，甚至可能是错的。不幸的是这些答案都没有检查过就被到处传来传去。
我会參考Stackoverflow上面的答案，由于这里的答案同行审查做的更好些。总的来说，像rose india这种站点就不要上了。上面的答案的质量差的离谱。假设你喜欢刨根究底的话，能够看看上面一篇文章里有多少拼写错误（类名以及专业术语）或者错误的言论。存在这些问题的一个原因在于没有一个有效的反馈机制来纠正这些错误。
文章来自： http://it.deepinmind.com/java/2014/05/10/common-java-myths.html