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

java框架学习方式有哪些？

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

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

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

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

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

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

4、nat 穿透 源码遇到问题

       遇到不会做的问题，当然不能置之不理。先在网上查，目前网络上针对很多问题都有完美的解决方案，如果网上没有类似的问题，那可能是你犯了什么小错误。也不要在这个问题上花费太多时间，这需要一定的学习技巧。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，hook偷源码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，cors filter源码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 中，这样的优化已被实现，允许编译器在某些情况下合并这些操作，以提高程序性能。