优秀的程序员更重视阅读源码,不看源码那是假的

Java007 · · 1175 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

01

从事java开发的都知道java有个垃圾回收机制Garbage collection,要准确理解Java的垃圾回收机制,我们可以从:“什么时候”,“对什么东西”,“做了什么事情”这三个方面来分析。01、“什么时候”

“什么时候”即是GC触发的条件。GC触发的条件有两种:

  • 程序调用System.gc时可以触发;
  • 系统自身来决定GC触发的时机。

系统判断GC触发的依据:根据Eden区和From Space区的内存大小来决定。当内存大小不足时,则会启动GC线程并停止应用线程

 

 

 

新生代、老年代结构minor gc/full gc,还需要了解Minor GC 金额Full GC 触发条件

Minor GC触发条件:

  • 当Eden区满时,触发Minor GC。

Full GC触发条件:

  • 调用System.gc时,系统建议执行Full GC,但是不必然执行
  • 老年代空间不足
  • 方法去空间不足
  • 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
  • 由Eden区、From Space区向To Space区复制时,对象大小大于To Space可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小

02、“对什么东西”

要是在面试时,面试官问“对什么东西”,有的求职者回答 没有用的对象,按道理来说,这并没有错,只是这并不是理想的答案。要是能更进一步分析,那就更好了,GC操作的对象分为:通过可达性分析法无法搜索到的对象和可以搜索到的对象。对于搜索不到的方法进行标记。从root搜索不到,而且经过第一次标记、清理后,仍然没有复活的对象。

对于用可达性分析法搜索不到的对象,GC并不一定会回收该对象。要完全回收一个对象,至少需要经过两次标记的过程。

把问题具体化了一些,对类似这样的对象进行回收,相信能给你这次面试加分。

03、“做了什么事情”

这个问题,回答空间其实挺大的,笼统地回答删掉暂没有使用的对象,节省内存。也不能说有错误,但要是我们能把问题再具体化一些,效果会更好。

要想搞清楚所以然,这就要求我们平时在开发中,要多留意去看看源代码。阅读源码的好处:一方面可以我们从中学习代码的架构,编码风格等,另一方面有助于我们了解正在做的东西的实现原理,用到哪些算法、数据结构等。有助于我们知其然又知所以然。

02

那么我们如何阅读源码呢?正确的学习方法不仅能够让我们事半功倍,也能够让我们更容易理解来龙去脉。

作为一名初学者,刚接触源码,往往让初学者手足无措。我们可以先把源码安装起来编译起来,结合它的操作文档,熟悉其功能和它的api

要是遇到的英文文档,英文水平还可以,能让你阅读英文的水平大幅提升。

浏览源码的目录结构,了解各个目录的功能。从整体上理清这个工程由哪些模块组成,最好能自己手动画一份目录结构图。

经过前面两步相信你对这个工程有了初步的了解。

熟悉源码编码风格,是采用驼峰命名规则还是匈奴利亚法。平时在阅读时,不妨参考下面3点做法。

  1. 阅读源码时要是看到工具类,要尽量去熟悉。这一步的分析可以学习到源代码的系统架构方式。我们可以从中学到源码的编写技巧,有助于提高我们的编码能力。
  2. 结合一些安全规则,研究源码在安全方面是如何设计的。这样可以提高自己在安全方面的意识。
  3. 研究系统所用到设计模式,一样的功能实现,用到的设计模式可能相差很多,对比我们之前所作的东东分析设计模式。对于设计模式,笔者从遇到一位从事4年多Android开发的同事,对设计模式并不重视,譬如建造者模式,AlertDialog.Builder这个,项目里到处都用,可他就是不知道是怎么实现,其实AlertDialog.Builder就是使用了Builder模式来构建AlertDialog的。

纸上得来终觉浅,得知此事要躬行。我们可以写一些简单的demo,注意是要自己手动编写,不要想当然,并且调试出来,这样才能做到更加理解代码。好的,今天就给大家分享一些源码架构的资料

源码分析

程序员每天都和代码打交道。经过数年的基础教育和职业培训,大部分程序员都会「写」代码,或者至少会抄代码和改代码。但是,会读代码的并不在多数,会读代码又真正读懂一些大项目的源码的,少之又少。这也造成了很多错误看源码的方式。

那要如何正确的分析源码呢?

我们的目标应该放在最常用的框架上面,下面就介绍两个:一个是Spring,另一个是大家用来觉得一直不怎么出问题的Mybatis。

△spring源码

 

分布式架构

随着我们的业务量越来越大和越重要,单体的架构模式已经无法对应大规模的应用场景,而且系统中决不能存在单点故障导致整体不可用,所以只有垂直或是水平拆分业务系统,使其形成一个分布式的架构,利用分布式架构来冗余系统消除单点的故障,从而提高整个系统的可用性。同时分布式系统的模块重用度更高,速度更快,扩展性更高是大型的项目必不可少的环节。

 

 

 

微服务

关于微服务架构的取舍

在合适的项目,合适的团队,采用微服务架构收益会大于成本。

微服务架构有很多吸引人的地方,但在拥抱微服务之前,也需要认清它所带来的挑战。

需要避免为了“微服务”而“微服务”。

微服务架构引入策略 – 对传统企业而言,开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用,逐步探索及积累微服务架构经验,而非全盘实施微服务架构。

 

 

 

JVM和性能优化

 

 

 

今天就先分享到这,如果你对以上架构资料感兴趣的话可以加群:795632998,进群可以获取获取Java架构学习资料、源码、笔记,学习视频有Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术


有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1175 次点击  ∙  1 赞  
加入收藏 微博
被以下专栏收入,发现更多相似内容
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传