Java面试者存在的问题
应聘初级、中级的Java工程师，要求扎实的Java和计算机科学基础，掌握主流框架的使用。
应聘高级Java工程师或技术专家，需要对Java IO/NIO，并发，虚拟机等，要掌握底层源码，并对分布式，安全，性能等领域有进一步的要求。
Java面试者通常存在的问题：
“知其然不知其所以然”。虽然面试者做了多年技术，开发了很多业务应用，但似乎并未思考过种种技术选择背后的逻辑。这样的话，公司并不放心把具有一定深度的任务交给他，更重要的是，并不确定他未来技术能力的成长潜力有多大。如果团队所从事的是公司核心产品，工作于基础技术领域，那么就不需要那些“差不多”或“还行”的代码，而是需要达到一定水准的高质量设计与实现。
知识碎片化，不成系统。在面试中，面试者无法完整、清晰地描述自己所开发的系统，或者使用的相关技术。平时可能埋头苦干，或者过于死磕某个实现细节，并没有抬头审视这些技术。比如，有的面试者，有一些并发编程经验，但对基本的并发类库掌握却并不扎实，似乎觉得在用的时候进行 “面向搜索引擎的编程” 就足够了。这种情况下，无法确定这个面试者有高效解决复杂问题、设计复杂系统的能力。
1. 谈谈你对Java平台的理解
"Java是解释执行"对吗？
Java有两大特性，一是“Compile Once, Run Anywhere”，跨平台能力，二是垃圾回收(GC)，通过垃圾回收器回收分配内存，无需程序员操心。
日常接触的JRE包括JVM,Java类库，以及一些模块等，JDK则是JRE的超集，提供了编译器，诊断工具等。
通常，Java源代码首先通过Javac编译为字节码，然后通过JVM内嵌的解释器在运行时将其转为机器码。
但常见的JVM，比如Oracle JDK提供的Hotspot JVM，提供了JIT（Just-in-time）编译器（动态编译器），能够在运行时将热点代码编译成机器码，这种情况就属于编译执行，而非解释执行。
Java和C/C++编译的区别
Java的编译，编译Java源码生成的.class文件里的实际上是字节码，而非机器码。
在运行时，JVM通过类加载器Class-Loader加载字节码，解释或者编译执行，主流的Java版本，都是混合模式(-Xmixed)。
通常运行在 server 模式的 JVM ，会进行上万次调用以收集足够的信息进行高效的编译， client 模式这个门限是 1500 次。
Oracle Hotspot JVM 内置了两个不同的 JIT compiler ， C1 对应前面说的 client 模式，适用于对于启动速度敏感的应用，比如普通 Java 桌面应用；
C2 对应 server 模式，它的优化是为长时间运行的服务器端应用设计的，默认是采用所谓的分层编译（TieredCompilation）。
Java 虚拟机启动时，可以指定不同的参数对运行模式进行选择。
指定 “-Xint” ，只进行解释执行，不对代码进行编译，这种模式抛弃了 JIT 可能带来的性能优势。毕竟解释器（ interpreter ）是逐条读入，逐条解释运行的。
指定 “-Xcomp” ，这是告诉 JVM 关闭解释器，不要进行解释执行，或者叫作最大优化级别。
但这未必是最高效的。 “-Xcomp” 会导致 JVM 启动变慢非常多，同时有些 JIT 编译器优化方式，比如分支预测，如果不进行 profling ，往往并不能进行有效优化。
还有一种新的编译方式，即所谓的 AOT （ Ahead-of-Time Compilation ），直接将字节码编译成机器代码，这样就避免了 JIT 预热等各方面的开销。
比如 Oracle JDK 9 就引入了实验性的 AOT 特性，并且增加了新的 jaotc 工具。利用下面的命令把某个类或者某个模块编译成为 AOT 库。
jaotc --output libHelloWorld.so HelloWorld.class
jaotc --output libjava.base.so --module java.base
在运行时直接指定即可。
java -XX:AOTLibrary=./libHelloWorld.so,./libjava.base.so HelloWorld
而且，Oracle JDK支持分层编译和AOT协作使用，这两者并不是二选一的关系。参考文档：http://openjdk.java.net/jeps/295。
AOT也不仅仅是只有这一种方式，业界早就有第三方工具（如 GCJ 、 Excelsior JET ）提供相关功能。
另外， JVM 作为一个强大的平台，不仅仅只有 Java 语言可以运行在 JVM 上，本质上合规的字节码都可以运行，比如 Clojure 、 Scala 、 Groovy 、 JRuby 、 Jython 等大量 JVM 语言。