阿杜面试题.docx

JVM：JVM选择，谈谈32位和64位区别。答案：1、目前只有server VM支持64bit JVM，client不支持32bit JVM。? 2 、The Java Plug-in, AWT Robot and Java Web Start这些组件目前不支持64bit JVM? 3.本地代码的影响：对JNI的编程接口没有影响，但是针对32-bit VM写的代码必须重新编译才能在64-bit VM工作。? 4.32-bit JVM堆大小最大是4G, 64-bit VMs 上, Java堆的大小受限于物理内存和操作系统提供的虚拟内存。(这里的堆并不严谨)? 5.线程的默认堆栈大小：在windows上32位JVM,默认堆栈最大是320k 64-bit JVM是1024K。? 6.性能影响:? (1)64bit JVM相比32bit JVM,在大量的内存访问的情况下，其性能损失更少，AMD64和EM64T平台在64位模式下运行时，Java虚拟机得到了一些额外的寄存器，它可以用来生成更有效的原生指令序列。? (2)性能上，在SPARC 处理器上，当一个java应用程序从32bit 平台移植到64bit平台的64bit JVM会用大约 10-20%的性能损失，而在AMD64和 EM64T平台上，其性能损失的范围在0-15%.?32位与64位的比较则更加细微。x86-64 架构不仅在x86架构的基础上增大了寄存器，而且还增加了寄存器的数量。从基本上说这会带来更好的性能（因为更多的寄存器可以让编译器创建更好的机器代码）。然而很不幸，至今把Java从32位移到64位带来的只是性能的下降。它们都包括JIT编译器和垃圾回收功能（GC）,其性能关键在JIT编译器和垃圾回收功能的执行效率上。 JIT编译器实现了程序执行之前Java字节码到硬件机器码的动态翻译，其背后的思想在于，相比Java源代码，字节码更小也更容易编译，但付出的代价是需要在Java字节码编译为机器码时花上一点时间，但与直接把Java源代码编译为机器码相比，时间还是少得多的。在32位与64位的JVM中，相应的JIT在把Java字节码编译为最终的机器码时，所花的时间稍微有所不同，但还能进行一些优化；另外，在IBM与Sun这两个版本的客户端与服务端程序上，总体性能也会有所不同。 垃圾回收会收回对象不再需要使用的内存,它必须被经常执行以释放对象不再访问的Java堆。由于在32位与64位平台上，Java堆中的数据大小会有所变化，所以会因为32位与64位JVM的性能差异，然而指针越大越GC管理越困难,导致相应垃圾回收的性能也会有所不同。?GC理解，谈谈JVM优化。答案：1）Heap设定与垃圾回收。Java Heap分为3个区：Young，Old和Permanent。Young保存刚实例化的对象，当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。JVM的Heap分配可以使用-X参数设定，-Xms初始Heap大小-Xmxjava heap最大值-Xmnyoung generation的heap大小JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。为什么一些程序频繁发生GC？有如下原因：l?程序内调用了System.gc()或Runtime.gc()。l?一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。l?Java的Heap太小，一般默认的Heap值都很小。l?频繁实例化对象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String()。如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。经验之谈：1?．?Server?端?JVM?最好将?-Xms?和?-Xmx?设为相同值。为了优化?GC?，最好让?-Xmn?值约等于?-Xmx?的?1/3[2]?。2?．一个?GUI?程序最好是每?10?到?20?秒间运行一次?GC?，每次在半秒之内完成?[2]?。2）．Stack的设定 每个线程都有他自己的Stack。-Xss每个线程的?Stack?大小Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。3）、硬件环境硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CP