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

电子版的问题我前面回答别人的问题的时候已经提到了。这个问题我与出版社交流过，他们不愿意去出电子版本，我也不能个人以任何名义给别人传递电子版本，否则会被起诉。所以电子版本暂时还不会出来的，不过还是感谢您的支持，这本书有些样章可以先看下，也未必是适合所有人的，如果有什么细节可以与我交流，书呢只是一个载体，牛书很多，这个刚出来，我估计按照出版社目前的规则，暂时是不会出电子书的，呵呵，请能够谅解！

好吧，一个一个的看完了 我看消息上说的25号截止，我看这一天前还有回答 我就姑且一试了。

本人工作3年多了，对工作上的技术问题基本没什么问题，虽然不能和大牛比，知识那么丰富，但是也算能解决当前问题。
现在就是想问下，其实在工作中，考验一个人的能力的时候，除开纯技术而言，解决问题的能力和方法才是更为看重的，就和技术类比，实现一个功能，不同的人有不同的方法，但是站的高度不一样，思考问题的方式不一样，一点一点的细节积累起来 对整个系统会有莫大的影响， 我想知道怎么了解到自己是什么样的一个水平，找到自己的差距，提高自己的认知。

书很好，我准备入手一本，期待下册的内容！

多谢你的支持，你能看过9页的交流信息，我觉得你首先是一个耐得住烦的人，呵呵！两天前我正在回家的路上，所以没看到消息，请谅解！发现你也是四川的，难道是老乡？^_^

从我自身的角度来讲，我所倡导的本身其中很重要的其中很重要的一个点就是“解决问题的能力”，你有这种能力，其实已经不错，虽然我没接触过你本人，不过我觉得你的很多认知比很多人要好，由于我不清楚你的水平，所以我只能就自己所理解随便说一些，希望有可以沟通的地方。

或许你问的问题在前言部分有一些答案，正如你所讲，同一个东西实现方式有多种，很多人高度不同。不过可以引来另一个问题的侧面，就是实现这个东西的难度和深度，或者说所要求的水平，这或许是一个方面，在互联网行业体现比较明显一些。再说另一个角度，问题本身的难度和解决问题的程度是衡量水平的一个标准，问题的难度这个要看行业背景，有些是技术的，有些是业务的，解决问题的程度是一个人对全局是否吃得够透彻，如果是一个业务背景，它可能更加透彻了解业务中的相关细节，梳理清楚思路和方法，避免头痛医头脚痛医脚的问题，技术问题也是如此，站在高度很多人都会，不过很踏踏实实地站在高度梳理清楚许多“风险点”，将它们连根拔起，或将硬伤通过某些方式控制在可控范围内，是另一种能力。

有人能很快探究自己现在所不知道的知识，这除了技术，本身也是一种能力和心态，技术功底过硬是一种基础，在短期内要研究清楚自己所没有接触过的东西，还要比普通人的认知更高，要承受的心里压力也比较大，在我看来这类技术人员内心都有一股火气，只不过在没解决问题前都是憋着的，在我的书中之所以用特种兵迎难而上者，也就是想要说明一种心态，因为每一个人都会遇到自己没有解决过的问题，我们不可能针对每一个问题去聘请一堆人处理，因为有很多问题真的等到那个时候黄花菜都凉了，要战胜困难有技术功底是一种底气或者信心，但解决过程中还是要有各种心态的支持，还有对问题的看法，或者说一种见地。

有人能很快从深度认识一个问题的根本，因为学多了很多东西都是相通的，至少在思想上很相通，技术虽然表现形式各有区别，但底子都差不多，思想更是接近，底子够扎实的时候，面对一些新技术或框架，其实在看很多功能介绍的时候，你大概知道它是咋实现的了，如果不是特别复杂可以翻翻代码，你很清楚你调用的API是咋跑的，很清楚它使用了那些基础技术来实现这种框架或概念，了解内存和并发或许更加清楚程序在计算机中大概是咋运行的。在这个上面再升级一下就能够改造一些三方框架带来的问题，或者做二次包装，甚至于全部自己写都是有可能的。这些东西并非重复制造轮子，或者说是否是重复制造，要看业务背景，所付出的与所获得的是否成正比，这些得到的不能仅仅用数学加法做个短期的利益比较，有些时候可能还要看长远一点点。这个时候很多框架是思想的提供者，也同时让我们更加了解如何充分利用Java提供的一些基础技术，好与不好更会认识得更多，这也是看源码是对一个技术人员提高的重要途径之一，只是我们不要因为要去看源码而去看源码，不要因为内存结构而研究内存结构，不要因为原理而去研究原理。要么你要有兴趣，要么你为了解决问题，要么你为了梳理清楚整体架构，要么你在研究原理后你能搞清楚为什么要这么设计（例如JVM为啥要分代的，或者说不分代又会怎么样，分代到底为了啥，而不仅仅是为了分代所以分代，它就是真理，其实这玩意没有真理），我们之所以这样看待问题，是因为我们是技术的使用者。


有些时候做的工作不一样，对于解决问题这几个字的看法也会有所不同，例如运维人员对于解决问题更希望是短平快的点上，讲究的是问题的难度和解决问题的速度，能够越快解决问题，就可以减少整体的损失，当然也可能前期做很多方案参与，以避免问题，这个时候体现的是运维人员对于各种服务机制的选型能力，建立在它对某些领域的服务原理和性能指标有充分的了解的基础之上。研发者更多是在解决问题后梳理整体思路，从产品角度，从技术根本角度去改造、改善一些东西。

我简单探讨了下层次，但是仅仅是我个人YY，我的书上也是这样说的。我个人也不希望用一个简单的level来看一个人，因为看的侧面不同，就是不同，有些时候其实看的不仅仅是这些能力，还得看是否志同道合，呵呵！因为道不同，level的衡量标准自然不同。如果level定义了明确的点，其实更加会被某些人所利用，有些人即使达到所有的点，其实你整体感觉它还是不行，有的人达到一部分点，但是它确实出类拔萃，所以按照点对号入座，是一件比较蛋疼的事情。

要验证自己的能力有很多种方式，其中一个重要的方式就是交流，从交流中会有很多很多的体会，当然交流的方式又有多种，技术大会、技术群、论坛、与高手当面探讨、甚至于面试，呵呵！我觉得呢，level这个东西是一个虚幻的东西，我们有一些小定义，朝着某些方向去发展，但是如果真的将level阶级化就可能会导致自己到一定程度失去上进的动力，或许一个很高的level会让自己也无法接受别人的批评，因为很多时候我们会被一些title迷惑自己。

客观认识自我，有成长，有不断提升的认可就是在进步，功底是厚积薄发的，在本书里面其实我本人也不是特别希望读者因为一些知识点较真，更加不希望为了知识点里面的结果而较真，里面的许多知识点都是碎片化的，粗略看有点像面试题库，这些知识点或许读者一辈子都遇不到，你会遇到自己的知识体系（尤其是在源码篇，每个人都会遇到自己领域内所需要去阅读的源码，我即使将写10种源码，也无法包罗万象），或许我们更多的是一种探讨，一种对知识求真的心态，在研究问题本质的时候，这种思维习惯和心态是很重要的，至少从我的角度是这样的。因此，在前言我也提到，希望本书带给读者的不是知识点，而是一种方法、心态、功底、思想。

坐火车回家刚休息两天，写得有点多，有点乱，可能要稍微梳理下，希望对你有一些小帮助！

补充下，下册内容，在本书的前言中有提到（前言在介绍书籍要写的内容部分，专门有下册的部分），本来是一本书的，手稿的字数超出了与出版社当初合同的3-4倍吧，硬拆成上下册的，这样也有一些好处就是了，一个是适合人群不同，另一个看看是否读者接收这种口味的写法吧，呵呵！

拆分上下册后，单独看下册内容，我自己对内容有点不太满意，比较单薄，我不太想背个上册赚名气下册赚钱的骂名，呵呵，所以下册我还想打磨打磨，结合更多我个人在工作中的总结与实践，初步与出版社约定的时间是到年底我交稿给出版社。

“胖哥”不仅技术方面“胖”得有深度、有广度，而且为人方面也“胖”得有厚度。各位朋友提出的问题，总是非常认真地回复，真可谓德技双馨！

麻烦管理员把其他版块的广告删删干净，满页都是小姐情何以堪

看书的过程中，作者的知识体系丰富，真的感觉获益良多。

除了书中分享的知识，我想问点其他的问题：

1.书中分析问题的时候，会用到jvm自带的工具，eg: javap,我想知道的是，作者如何获取到这些工具的使用方法，或者用途.

呵呵，我简单说下哈：
1、交流，通过群、技术交流、学习群等进行交流。
2、官方文档，我外语不好，通常看关键点，然后自己做实验。
3、技术网站的推送资料，通常会发到邮箱，相关的会关注。
4、所有途径拿到的信息，如果有时间就实验下，如果没有时间就先将内容拷贝下来，找个时间来实验。
5、实验的方法网上有很多，官网更全，不过大多网上资料是零碎的，要拼接在一起需要有一些整理和思考。
6、拿到工具后，学会一种参数有一个感性认识，然后就看看help相关的内容。

我一般是这样的^_^

楼主很有魅力啊 书刚刚已经拍下 楼主有没有什么技术交流群之类的？