高手问答：Java老A带你全面提升Java单兵作战能力！

不知道书里面对jvm有无讲解啊 不过看前面的部分目录 还是很吸引我的
后面去买一本读读

关于你说的部分对象不是分配在堆上的问题，这个其实是非Java的对象，Java对象不会出现，有些经过Java对象包装后的底层对象会在C Heap中有空间（例如DirectByteBuffer，但是它的实体不是Java对象，Thread也是类似的，它在start()后也是使用native空间）。
JIT主要是运行时的优化策略，更多是代码段上，数据上不会做什么太大变化，实际对象里面放的就是数据嘛，代码段的优化有很多，有些是动态inline、压缩汇编指令、本地代码cache等。

接下来的问题在书上也有所体现，不过那些仅仅是代表个人看法，没有任何官方说明。
你下面提到了方法区的问题，也就是在永久代里头，大部分情况下认为够用就好，GC也不需要关注，这样GC扫描的空间自然会少一些，配置永久代一般够用就好，没必要配多大，因为配置大了也是浪费，对象常规情况下也不会跑这里面来，注意的是这块空间不是把应用中所有的类和jar中所有的类都装到内存中，而是你用到的相关的类才会被加载，且在通过ClassLoader中只加载一次，大部分应用中会发现永久代使用比较稳定，而且使用量也不多，如果发现使用比较低，可以将空间留给堆来使用，因为它大部分情况下就是够用就好。

不过Java里头越来越多的技术导致这块区域也会经常动态变化，包括方法区也是这样的，比较典型的就是字节码增强的技术，热部署等，它们会导致方法区有所变化，另外这个区域以前是在永久代里面，永久代的膨胀不仅仅取决于Class本身，例如String的intern()在1.6及以前的版本也会放入永久代，JDK 1.7先把这一块剥离出来了，因为永久代满的时候导致的是FULL GC，既然这块空间可变化，它就应当属于普通堆内存的特征。

其实在其它JVM中（也就是除Hotspot VM外），没有永久代的概念，就Hotspot VM有这玩意，其它很多JVM都比这个东西跑得好，你说的Java 8的元空间我还没有研究过，因此我不敢对任何细节妄下断言。敢说的就是Java目前的发展肯定是希望写代码的人越简单的写法来写代码，复杂度会越来越少。Java的GC肯定会越做越好的。加载的方式理论上不会有什么太大变化，只是存放的位置会变化，这些应当对开发者的使用来讲更加没有什么影响的。至于GC方式，我认为要么你说的元信息在GC层面是独立的（和永久代类似，但更细化了），要么和堆一致，也不会造成什么影响，因为这块空间本身很有限，加上G1的一些机制，垃圾优先原则，肯定是变好的，而不是让我们针对某个Java版本去改更多的代码，至少应该不会针对一些已经存在的特征大量修改代码，对于新特征是可以选择性利用，例如JDK 1.6的高级锁，JDK 1.7的fock join，程序中可以选择用老的方式还是新的方式，在内在机制发生一些细节改变，也通常可以选择性的，如果不具有选择性，那肯定是更佳的方案，就像底层的锁优化肯定是变好，所以升级JDK后在不需要改代码的情况下，锁的性能理论上就是比以前高，至少应该可以能持平，这个是我的理解。

首先JVM参数的细节应该是通过其它方式来看，比较简单的就是通过jmap -heap就可以看到一些基本参数，还有一些是通过jstat -gccapacity、jinfo等可以看到，jinfo需要一定的版本支持。

启动参数其实有些时候并不是那么重要，因为运行时是可以动态调整的，如果就你的JVM来讲，应该是默认输出，还谈不上启动参数，有些参数没设置，不代表它没有值，而且启动参数有好几百个，所以反过来推启动参数意义并不是特别大，就你给出的日志来讲，Young空间第一句说明：
def new generation   total 6464K, used 115K [0x34e80000, 0x35580000, 0x35580000)
这个6464K其实有点点问题，实际值是你说的7M，也就是5760K+704K+704K，它算的空间是Eden+一个Survivor空间，这个默认启动是采用串行GC方式，很多输出都这个鸟样子，或许它认为实际使用的就这么多吧。

这个地址范围我不多说了，你也知道咋算出来的，Eden、S0、S1也比较明显了，Eden大概是S0或S1的8倍左右，这也与SurvivorRatio的默认值8匹配。

tenured generation   total 18124K, used 8277K [0x35580000, 0x36733000, 0x37680000)
   the space 18124K,  45% used [0x35580000, 0x35d95758, 0x35d95800, 0x36733000)

这个明显是-client模式下的串行GC启动，不过在64bit下的JVM没有串行client这个分支了，使用了不会报错，也没有警告，但是启动的依然是server级别的，这个启动应该是在32bit下用的。

tenured generation这个是串行GC中老年代回收的算法名称，也是串行GC的代名词，总共有18124K，这个和上面年轻代的显示不一样，这个也是串行GC比较恶心的日志地方，18124K是当前老年代的大小是0x36733000-0x35580000=18M，不过老年代最大的大小是0x37680000-0x35580000=33.7M左右，也就是-Xms和-Xmx是不同的值，或者只设置了其中之一，或直接采用JVM默认。加年轻代，-Xmx大概是在40M+的样子。

老年代的第二句描述了它的使用情况，通过计算也可以算出来确实是45%。


最后是永久代：
compacting perm gen  total 16384K, used 16383K [0x37680000, 0x38680000, 0x38680000)
永久代总共16384K（16M），使用了16383K，从数字上看永久代空间满了。


不过这些数字是JVM输出的日志，它是否存在什么问题不一定（这种问题发生过不止一次），尤其是这类GC日志的输出，仅仅通过这个日志还推断不出太多东西出来，在串行GC上的细节我看得并不多，能讲的大概如此，希望可以帮助你理解。再说下哈，目前看参数一般不是通过这种方式看的，呵呵！

看了目录应该知道本书有地方是讲JVM的，第3章可以算是完全讲JVM的，第5章也算吧，其实书的前后文字之中贯穿JVM的一些东西理解，不过我并不是JVM的专家，所以在JVM的专业性上肯定有所差距，并且讲解JVM的书籍有专门的书籍，国际大师写得有，过内也有顶尖高手写过，还有JVM神一样的人物有虚拟机的各种内核介绍（如R大），因为他们是参与虚拟机开发的，深入程度领先我不知道多少光年。

我的书上写JVM有两个目的，一个是站在一个普通程序员的角度，我觉得差不多应该去了解哪些东西，会阐述JVM这个知识点可能会对写代码有什么认知，第一章讲到String、Integer、集合类有一个粗浅的说明，后面章节会有很多相对深入说明，我们是通过理解虚拟机，然后回归到一些代码场景，希望去帮助我们写代码，帮助我们更好的了解内在的一些机制基础上去写代码，或许写一些核心程序的时候不是在猜、应该，而是很有底气，相对自信一些，因为你闭着眼睛都知道大概是咋在运行。

第二个目的就是一个小的引导性，让大家对这个感兴趣，让你觉得它对你的程序是有帮助的，希望大家去学会注重原理，或许这些引导性的JVM知识，可以让你在这个方面深入造诣，因为这些JVM知识最多最多算是入门级别。前6章的知识我都希望读者能细心去看，至少通过几次阅读能看懂半多的内容，加以实践，就能有许多新的体会。

在阅读样章，听说有书送，求书，不过看完觉得不错没送也会掏钱买

这个我在问下出版社同学是否还有量，你可以先私信我下，大量送的话出版社的同学也招架不住，呵呵！

哈哈，已私信，只看了部分样章，觉得比单纯的工具类书有趣，自己是边看边跟着操作，有些知识以前也看过，感觉加深了影响，引起了自己的思考，总体感觉还不错

谢谢你的支持，希望能够给你带来一些帮助，书的目的也是希望大家有更多的思考和探讨，与实践多结合，而不是为那个结果较真，我最害怕的就是某些小伙伴为结果较真，高手可能为结果较真就当我太low了，无所谓，初学者如果为结果较真可能就会被误入歧途，所以一直定位是工作时间不太久但渴望进步的人。

能剧透一些Java特种兵 下 里面的内容吗？
下会包含那些内容？

没什么不可以的，下册的内容在上册的前言中就有的，本来是一本书的，没有什么上下册，主要是字数超出了出版社的要求好几倍，硬拆成上下册的，下册手稿和上册的手稿都是年初完成的，目前就上册和出版社修订了几次出版了，我主要看下这本书真的是否适合大家再考虑出下册，如果觉得上册写得烂的话，也少花点冤枉钱，呵呵！

前言部分在这个博客中有的：http://blog.csdn.net/xieyuooo/article/details/38612913
其中第3篇~第5篇就是属于下册内容。
简单说，下册是写的东西更多要虚一点，设计、实现、一些技术坑、一些技术小原理、思考、人际、沟通、量化成本、集群、分布式、程序员的心态等等。或许对比上册没多大吸引力，这也是上册更适合大众的原因。