java是从什么语言改进重新设计的？
Sun公司的James Gosling领导的绿色计划(Green Project)开始着力发展一种分布式系统结构，使其能够在各种消费性电子产品上运行，他们使用了C/C++/Oak语言。由于多种原因，绿色计划逐渐陷于停滞状态。从而java诞生。我觉得java语言应该更像c++我说的是语言特性，不是指后来web开发
后来J2EE与C++那就远了，如果从语法基础上讲应该更像C++。我也不知道对不对！
java解释执行后是否常驻内存？为何需要JIT技术？
什么是 JIT ？
为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler），简称 JIT 编译器
什么是编译和解释？编译器：把源程序的每一条语句都编译成机器语言,并保存成二进制文件,这样运行时计算机可以直接以机器语言来运行此程序,速度很快;
解释器：只在执行程序时,才一条一条的解释成机器语言给计算机来执行,所以运行速度是不如编译后的程序运行的快的；
通过命令将 Java 程序的源代码编译成 Java 字节码，即我们常说的 class 文件。这是我们通常意义上理解的编译。
字节码并不是机器语言，要想让机器能够执行，还需要把字节码翻译成机器指令。这个过程是Java 虚拟机做的，这个过程也叫编译。是更深层次的编译。（实际上就是解释，引入 JIT 之后也存在编译）
此时又有疑惑了，Java不是解释执行的吗？
没错，Java 需要将字节码逐条翻译成对应的机器指令并且执行，这就是传统的 JVM 的解释器的功能，正是由于解释器逐条翻译并执行这个过程的效率低，引入了 JIT 即时编译技术。
必须指出的是，不管是解释执行，还是编译执行，最终执行的代码单元都是可直接在真实机器上运行的机器码，或称为本地代码
附一张图来理解
image编译原理参考：深入分析Java的编译原理
为何 HotSpot 虚拟机要使用解释器与编译器并存的架构？解释器与编译器两者各有优势
解释器：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。
编译器：在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。
两者的协作：在程序运行环境中内存资源限制较大时，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。当通过编译器优化时，发现并没有起到优化作用，，可以通过逆优化退回到解释状态继续执行。
即时编译器与 Java 虚拟机的关系即时编译器并不是虚拟机必需的部分，Java 虚拟机规范并没有规定 Java 虚拟机内必须要有即时编译器的存在，更没有限定或指导即时编译器应该如何去实现。
但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一。它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。
即时编译器的分类- Client Compiler - C1编译器
- Server Compiler - C2编译器
目前主流的 HotSpot 虚拟机（JDK1.7 及之前版本的虚拟机）默认采用一个解释器和其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，就是文章开头提到的两种模式。
在 HotSpot 中，解释器和 JIT 即时编译器是同时存在的，他们是 JVM 的两个组件。对于不同类型的应用程序，用户可以根据自身的特点和需求，灵活选择是基于解释器运行还是基于 JIT 编译器运行。HotSpot 为用户提供了几种运行模式供选择，可通过参数设定，分别为：解释模式、编译模式、混合模式，HotSpot 默认是混合模式，需要注意的是编译模式并不是完全通过 JIT 进行编译，只是优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。
分层编译产生的原因：由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且要想编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机启用分层编译的策略
分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次：
第 0 层：程序解释执行，解释器不开启性能监控功能，可触发第 1 层编译。
第 1 层：也称为 C1 编译，将字节码编译为本地代码，进行简单，可靠的优化，如有必要将加入性能监控的逻辑。
第 2 层（或 2 层以上）：也称为 C2 编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后，Client Compiler 和 Server Compiler 将会同时工作，许多代码都可能会被多次编译看，用 Client Compiler 获取更高的编译速度，用 Server Compiler 获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。
编译优化技术Java 程序员有一个共识，以编译方式执行本地代码比解释执行方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个重要的原因就是虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器中，因此一般来说，即时编译器产生的本地代码会比 javac 产生的字节码更优秀。以下是具有代表性的 HotSpot 虚拟机的即时编译器在生成代码时采用的代码优化技术：
- 语言无关的经典优化技术之一：公共子表达式消除
如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那么 E 的这次出现就成为了公共子表达式。对于这种表达式，没必要花时间再对它进行计算，只需要直接使用前面计算过的表达式结果代替 E 就可以了。
例子：int d = (c*b) * 12 + a + (a+ b * c) -> int d = E * 12 + a + (a+ E)
- 语言相关的经典优化技术之一：数组范围检查消除
在 Java 语言中访问数组元素的时候系统将会自动进行上下界的范围检查，超出边界会抛出异常。对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，这无疑是一种性能负担。Java 在编译期根据数据流分析可以判定范围进而消除上下界检查，节省多次的条件判断操作。
- 最重要的优化技术之一：方法内联
简单的理解为把目标方法的代码“复制”到发起调用的方法中，消除一些无用的代码。只是实际的 JVM 中的内联过程很复杂，在此不分析。
- 最前沿的优化技术之一：逃逸分析
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中杯定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。
如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可以为这个变量进行一些高效的优化：
- 栈上分配：将不会逃逸的局部对象分配到栈上，那对象就会随着方法的结束而自动销毁，减少垃圾收集系统的压力。
- 同步消除：如果该变量不会发生线程逃逸，也就是无法被其他线程访问，那么对这个变量的读写就不存在竞争，可以将同步措施消除掉（同步是需要付出代价的）
- 标量替换：标量是指无法在分解的数据类型，比如原始数据类型以及reference类型。而聚合量就是可继续分解的，比如 Java 中的对象。标量替换如果一个对象不会被外部访问，并且对象可以被拆散的话，真正执行时可能不创建这个对象，而是直接创建它的若干个被这个方法使用到的成员变量来代替。这种方式不仅可以让对象的成员变量在栈上分配和读写，还可以为后后续进一步的优化手段创建条件。
按自己理解整理的，知识点顺序不知是否合适，还请大家指导。
也不是Java程序员，简单谈谈我的看法。
1，一般意义上的垃圾回收是针对对象实例，而非类型本身，要回收类型，需要从 Classloader 入手;
2，Java是编译型语言，但不是原生编译，编译结果是中间代码（字节码），这就是能跨平台的原因，因此程序运行时需要从中间代码转换为机器码;
3，将中间代码编译成机器码有时间开销，而且和中间代码的量是成正比的，就是说要编译的越多，花费的时间就越多，程序的启动速度就越慢; 这也是所有使用中间语言（如Java、C#等）开发的程序，启动速度明显比原生编译型程序要慢的原因;
4，JIT的作用是按需编译，用到才编译，编译后缓存，可以提高程序的加载速度，效果立竿见影;
某屌炸天的编译器，就是在中间代码的编译阶段，直接编译成机器码，相当于原生编译，这样输出的程序虽然加载和运行速度有所提高，但失去了跨平台的能力。
如何理解java中的反射？
JAVA中的反射无处不在，不仅在jdk中存在，还在诸如spring，mybatis，设计模式等中广泛使用！
首先要知道的是，JAVA可以算做编译型语言，大多数的类，方法都在编译时已经明确，这显然不能满足于我们所有的需求，使用反射就可以在运行时动态加载，通过类可以构造对象，准确的知道它的属性，方法等全部信息！
JAVA中的反射方式有以下几种：
①Class.forName（“类全路径”）；
②对象名.getClass
③基本类型的包装类：Boolean.TYPE，Integer.TYPE等！
反射的作用有：
1，可以在运行时动态获得对象，
2，在运行时动态获取一个类的构造器，方法，变量，注解等！
3，实现动态代理。
反射的缺点:因为是在运行时获取，没有JAVA的预编译，在运行时性能存在问题！
反射的实际使用场景：
1，spring中实例化对象的时候如果都用new来创建对象，那将会十分繁琐，而且加入新类型的时候也需要重新new，spring的做法是让这些所有对象继承自beanDefinition，这样在实例化的时候，只要传入父类和子类类型即可！
2，动态代理：spring aop中的注释模式就是用了动态代理，比如JdkDynamicAopProxy
反射在实际开发中也是体现一个开发人员水平高低的参考，要让这种思想深深烙入心里，在实际开发中解决很多后期扩展困难的问题！需要反射Demo的可以私信我索取，近期一直在分享JAVA开发方面的东西，有些很不错，敬请关注。。
反射就是为了程序运行中的时候通过反射获取类的方法和属性，可以进行修改，现在大众都知道的spring框架里面的IOC就是应用了反射创建类，当业务需要的时候可以直接注入，不需要自己去创建
反射就是在运行期获取类型信息，Java反射更进一步，还允许修改一些信息。至于如何实现的，是在编译期间将相关信息（类型元数据）放在class文件中，在运行时候可以将这些信息封装成特定Java对象供系统使用。其实C++和Delphi等语言都可以提供（但程度稍低）RTTI信息供运行时使用，但是以函数形式提供。
因为编译器在编译期知道所有的类型细节信息，所以，只要需要，任何语言都可以提供反射功能。
还没有评论，来说两句吧...