皮皮网

1.java框架学习方式有哪些？
2.Java中9种常见的源码CMS GC问题分析与解决（下）
3.java中关于instanceof的问题?

java框架学习方式有哪些？

       1、打好基础是分析重中之重

       基础部分可能很枯燥，但是源码一定要耐心坚持下去。因为打基础好比是分析在造轮子造汽车，没有打好基础在后面的源码学习就好比走路，可以说后面遇到的分析etty 源码解析百分之七八十的问题都是基础没学好造成的。

2、源码多看官方文档多读源码

       一定要看JDK相关类库、分析常用框架各种功能的源码源码，去了解其底层实现的分析原理。总的源码来说这个也是在打基础的部分，Java基础非常扎实才能看懂，分析在我们学习一个类的源码源码时，肯定会衍生出其他各种各样的分析问题，供我们来了解和学习，源码这也就是我们下一步学习的目标和方向。慢慢的，我们就会学习更多的知识，并积累更多的经验。

3、系统性学习，循序渐进

       不要急于求成，每个知识点都要看，并且每个知识点都要勤加练习。有的同学在学习过程中觉得这个知识点简单，就跳着学习，其实这是个很大的问题，知识点细节必须要了解。我们学习Java需要循序渐进，一步一步来，不能操之过急。

4、asp博客导航源码遇到问题

       遇到不会做的问题，当然不能置之不理。先在网上查，目前网络上针对很多问题都有完美的解决方案，如果网上没有类似的问题，那可能是你犯了什么小错误。也不要在这个问题上花费太多时间，这需要一定的学习技巧。Java中的知识有很强的相关性，有不懂的地方，可以用其他周边相关知识再回过头来理解，这样既不会耽误学习进度，又能理解自己不懂的地方

1）jvm有很多种，其实jvm是一个标准，sun做的那个叫hotspot，作者就是后来v8的作者lars bak，其他公司也做过jvm，其中做得比较好的有bea的jrockit，其他的包括ibm的r9，apple的jvm等在内，都做得不行，所以jvm主要是整合淘汰掉这些做得不好的jvm(s)，整合成一个统一的openjdk。

2）java是典型的oop语言，其执行效率的优化，最早就是lars bak等人从smalltalk等长期优化的经验中总结出来并apply到hotspot上去滴，而smalltalk在早期apple机上搞出了那种拖拖拽拽就开发出app的做法，后来vc，delphi之类的其实都是抄袭或者说借鉴apple的smalltalk的做法，jobs说微软从头到尾都在抄袭apple是空穴来风，这里空穴来风跟王垠使用的前景背景提取源码空穴来风是一个意思，有趣的是，java的gui并没有继承这种搞法，反而对这种拖拖拽拽就作出app的做法批判有加，到今天，其实java的gui都还不能真正做到拖拖拽拽就作出来，问题很多，个人建议对于纯java的gui开发，还是以写代码为主。

3）jee也是一个或者说是一堆标准，知乎上有些人把maven，jenkins都算做jee是不对滴，jee的标准核心是ejb，其实就是一个xml配置化的java文件，这个标准在4的时候，达到了顶峰状态，几乎所有的挨踢大厂都主动支持该标准，之后开始走下坡路，支持的厂越来越少。

4）java和javascript的关系比很多人认为的要密切，javascript里面的java这四个字母可不是白叫的，比如js的版权和商标都控制在oracle手里，oracle对于js的支持甚至超过其对java的支持，并且喜欢捆绑销售，比如jvm里面就有一个js引擎。

5）jvm里面除了js engine以外还有一个浏览器排版引擎webkit，就是apple safari和google chrome用的那个那个。

6）java支持绝大多数脚本语言，你能叫得上名字的脚本语言，几乎都可以在jvm上执行，比如常见的js，ruby，https网站源码下载python，甚至php，lua，只不过除了js以外你需要找到相关的脚本引擎。

7）spring的版权被控制在vmware手里，其实spring的那一大堆东西，本质上是一个非标准的jee实现，比如在jee里面用的inject，在spring里面就是autowire，当然spring曾经深刻滴影响了jee，所以有些东西比如di标准，是spring影响下制定出来的，所以spring的做法会比较特例一点。

8）maven上的jars数量前两天突破万，其他语言的类库，排名第二的是npm，大概数量是maven的十分之一，也就是几十万，不知道现在突破万没有，然后是gem，也就是ruby那个，大概是十几万，下来是python的module，大概数量级是几万，没突破十万。

9）java的标准是由一个叫做jcp的组织制定的，所有标准需要经过jcp的执行委员会通过方可执行，jcp几乎包括了你所知道的绝大多数知名挨踢公司和组织，比如google，apple，ibm，试客助手源码intel，arm，red hat，twitter等，还有一些教育机构，比如我国的北京大学，阿里最近一次申请jcp执行委员会成员资格，似乎投票不通过，最近一次执行委员会新增两个成员是arm和jetbrains。

）微软也曾经是jcp甚至是java的主要贡献者，但是利益驱使下，想扩展java，从而破坏java跨平台的特性，所以跟sun闹翻，其本质原因就是想让客户写的java代码跟windows绑定，sun坚决不同意，闹翻，今天回头看这个结果，只能说：双输，sun挂了，微软的ria也离挂不太远了，silverlight已经放弃了，比起当年ie自带有jvm的支持来说，那完全就是两回事。

）除了微软以外，jcp还缺少一个重要组织apache，因为apache跟oracle也闹翻了，oracle似乎并不在乎开源组织，而更在意商业公司的支持。

）java曾经有一个内置的数据库，9之后被剥离。

）j2me是j2se的子集。

       ）vert.x作者tim fox最早在vmware做spring时候看到了node.js，萌生出了制作支持多核的node.x的想法，并在离开vmware后加入red hat将其实现，vmware看到后开始耍无赖，claim node.x后来改叫vert.x的版权，不惜跟red hat打官司，后来各方妥协，将其交给eclipse foundation。

）oracle在收购bea之前，一开始的目标并不是bea和bea的weblogic，而是jboss，但是jboss表现出了极为有种的一面，在oracle收购成功之前，投入了red hat的怀抱，因为都是开源组织，从此jboss成了red hat的一个子部门，oracle收购jboss失败之后，转向bea，庄思浩气死了，但是没用，最后还是被恶意收购。

）sun在玩不下去之前最早尝试接触的目标是ibm，ibm嫌太贵，放弃之后，被转手给了oracle。（Java学习交流QQ群： 我们一起学Java！）

       ）vert.x的作者tim fox在离开red hat之前曾经发过twitter抱怨，外人比如我们，猜测是因为red hat内部已经有了一个jboss，所以跟vert.x在应用上有了重叠，所以导致tim fox的出走，但是出走之后，red hat答应对vert.x做持续性的战略投入，所以vert.x core的几个developers，其实拿的是red hat的工资，但是vert.x的版权并不在red hat手里，而在eclipse foundation手里。

       ）vert.x的几个核心开发人员都是google summer of code的导师，每年年初时候会招收在校大学生搞项目。

       ）教育机构相关：scala的作者马丁是德国人，eth的博导，groovy的主要***是法国人，jruby背后是东京大学，jboss的作者是法国大学校x的校友，x就是伽罗瓦考不进去的那所大学，伽罗瓦进不了x，所以改读巴黎高师，tim fox毕业于帝国理工，主席去的那个，netty作者trustin lee是acm银牌，现在line工作，毕业于sky里面的延世大学，kotlin是毛子公司jetbrains的作品，看linkedin，很多人毕业自圣彼得堡大学，spring作者rod johnson是悉尼大学的音乐博士，hibernate作者gavin king是澳洲莫那什大学的数学本科毕业生，james gosling这种cmu和calgory的估计烂大街了，sun是斯坦福大学网络的意思，夹带两个私货，aspectj有一个维护小组在mcgill，hbase跟waterloo关系密切。

       ）java早期被人认为慢，跟java坚持不用硬件加速渲染有关，死活就是不肯接入directx和opengl，7之后总算开窍，搞了一个图形引擎接入了directx／opengl。

       ）casssandra是facebook做失败的项目，被贡献给了apache之后老树开花。

       ）groovy被贡献给了apache，现在叫做apache groovy，ceylon被贡献给了eclipse，现在叫做eclipse ceylon。

       ）netflix现在是java shop，之前是用.net的。

       先想到这么多，有空再写。

Java中9种常见的CMS GC问题分析与解决（下）

       Java中9种常见的CMS GC问题分析与解决（下）

       美团技术团队通过对内部GC问题的深入研究和总结，针对Hotspot VM中CMS + ParNew组合的复杂场景，提供了深入的分析和实用的解决方案。本文主要聚焦于以下几个关键问题：

场景六：单次CMS Old GC耗时长

       分析了长时间STW的原因，主要集中在Final Remark阶段，通过理解核心代码和步骤，提出了针对性的优化策略。

场景七：内存碎片与收集器退化

       探讨了内存碎片导致的收集器退化，包括晋升失败和并发模式失败，提供了解决策略，如监控内存碎片率和避免大对象产生。

场景八：堆外内存 OOM

       剖析了堆外内存泄漏的两种原因，通过NMT和JNI调用的排查方法，提供了解决方案。

场景九：JNI引发的GC问题

       针对JNI调用可能导致的GC，解释了GC Locker机制及其潜在影响，并给出了相应的策略。

       整体而言，处理这些问题的关键在于理解根源、合理配置参数、监控内存使用情况，并在必要时深入阅读源码。在遇到GC问题时，主动分析和优化是提升系统性能的关键。

java中关于instanceof的问题?

       Java编程语言中，`instanceof` 关键字用于检查一个对象是否属于指定类或其子类的实例。`instanceof` 的关键点在于静态与动态语义：静态类型指的是源代码中定义的类型，而对象的实际类型在运行时确定。

       Java 的类型系统是静态的，这意味着在编译时，引用的类型就已经被确定。例如，你声明一个变量 `obj` 为 `Object` 类型，这意味着 `obj` 仅能引用 `Object` 类型的对象，或者其子类的对象。

       然而，当通过赋值操作将一个具体子类的对象赋予 `obj` 变量时，`obj` 的静态类型保持不变，但实际指向的对象类型转变为子类。例如：

       Object obj = new Foo();

       这里，`obj` 的静态类型是 `Object`，但实际指向的是 `Foo` 类型的实例。

       `instanceof` 运算符的运行时语义则更为灵活，它不关注引用的静态类型，而是检查引用所指向的对象的实际类型是否符合指定的类或接口。例如：

       if (obj instanceof Foo) {

        // 执行Foo的特定操作

       }

       即使 `obj` 的静态类型是 `Object`，只要它实际指向的是 `Foo` 类型的实例，`instanceof` 将返回 `true`。

       至于为何 Java 提供了 `instanceof` 运算符之外，还提供了 `java.lang.Class.isInstance(Object)` 方法，虽然这两者在运行时语义上一致，但 `isInstance` 方法在某些场景下更加灵活，因为它允许传入 `Class` 对象的实例，而不仅仅是类名。

       将 `isInstance` 用作 `instanceof` 的替代，特别是当检查条件为常量时，可以实现代码优化，使得编译器能够对代码进行优化，从而提升性能。

       许多现代 JVM 的 JIT 编译器会自动将 `isInstance` 方法调用优化为 `instanceof` 操作，以减少代码执行的开销。例如，在 HotSpot JVM 中，这样的优化已被实现，允许编译器在某些情况下合并这些操作，以提高程序性能。