作者小傅哥多年从事一线互联网Java开发,从19年开始编写工作和学习历程的技术汇总,旨在为大家提供一个较清晰详细的核心技能学习文档。如果本文能为您提供帮助,请给予支持(关注、点赞、分享)!
大部分考试考的,基本都是不怎么用的。例外的咱们不说😄 就像你做程序开发,尤其在RPC+MQ+分库分表,其实很难出现让你用一个机器实例编写多线程压榨CPU性能。很多时候是扔出一个MQ,异步消费了。如果没有资源竞争,例如库表秒杀,那么其实你确实很难接触多并发编程以及锁的使用。 但!凡有例外,比如你需要开发一个数据库路由中间件,那么就肯定会出现在一台应用实例上分配数据库资源池的情况,如果出现竞争就要合理分配资源。如此,类似这样的中间件开发,就会涉及到一些更核心底层的技术的应用。
开始听这句话还在上学,既不卓越、也不优秀,甚至可能还有点笨!但突然从某次爬到班级的前几名后,开始喜欢上了这种感觉,原来前面的风景是如此灿烂😜! 优秀和卓越差的不是一个等级,当你感觉自己优秀后,还能保持空瓶的心态开始,才能逐步的像卓越迈进,并漫漫长! 是不小时候更容易学会更多的知识,但越大越笨了!人可能很容易被自己的年纪大了,当成长者。却很少能保持一个低姿态谦卑的心态,不断的学习。所以最后,放不下自己,也拾不起能力。
是不是你看见过的突飞猛进都是别人,但自己却很难! 其实并没有一天的突飞猛进,也没有一口吃出来的胖子。有得更多的时候日积月累、不断沉淀,最后才能爆发、破局! 举个简单的例子,如果你大学毕业时候已经写了40万行代码,还找不到工作吗?但40万行平均到每天并不会很多,重要的是持之以恒的坚持。
千万不要总自我否定,尤其是职场的打工人。如果你经常感觉,这个做不好,那个学不会,别的也不懂,那么久而久之会越来越缺乏自信。 一般说能成事的人都具有赌徒精神,在他们眼里只要做这事那就一定能成,当然也有可能最后就没成,但在整个过程中人的心态是良好的,每天都有一个饱满的精神状态,孜孜不倦的奋斗着。最后也就是这样的斗志让走在一个起点的小伙伴,有了差距。
最近经常有小伙伴问我,以为我的经验来看,学多少够,好像更多的是看你的野心有多大。如果你只是想找个10k以内的二线城市的工作,那还是比较容易的。也不需要学数据结构、也不需要会算法、也需要懂源码、更不要有多少项目经验。 但反之我遇到一个国内大学TOP2毕业的娃,这货兼职是Offer收割机:腾讯、阿里、字节还有国外新加坡的工作机会等等,薪资待遇也是贼高,可能超过你对白菜价的认知。上学无用、学习无用,纯属扯淡! 你能在这条路上能付出的越多,能努力的越早,收获就会越大!
这是最近我总能被问到的问题,也确实是。一个初入编程职场的新人,或是一个想重新努力学习的老司机,这也不会,那也不会,总会犯愁从哪开始。 讲道理,毕竟 Java 涉及的知识太多了,要学应该是学会学习的能力,而不是去背题、背答案,拾人牙慧是不会有太多收益的。 学习的过程要找对方法,遇到问题时最好能自己想想,你有哪些方式学会这些知识。是不感觉即使让你去百度搜,你都不知道应该拿哪个关键字搜!只能拿着问题直接找人问,这样缺少思考,缺少大脑撞南墙的过程,其实最后也很难学会。
一、码场心得 二、面试题 三、volatile 讲解 1. 可见性案例 2. 加上volatile关键字 3. volatile怎么保证的可见性 4. 反编译解毒可见性 5. 不加volatile也可见吗 四、总结 五、系列推荐
其实技术宽度与技术深度是相辅相成的,你能了解多少技术是和你对一个技术的理解深度有关,而你能对一个技术探究的多深又是需要你有一定的广度认知。否则如果只去了解皮毛或者死磕一段代码,收获都不一定有多大,或者要付出很大的成本。
面我的题开发都用不到,你为什么要问?可能这是大部分程序员求职时的经历,甚至也是大家讨厌和烦躁的点。明明给的是拧螺丝的钱、明明做的是写CRUD的事、明明担的是成工具的人! 「明明... 有很多」,可明明公司不会招5年开发做3年经验的事、明明公司也更喜欢具有附加价值的研发。有些小公司不好说,但在一些互联网大厂中,我们都希望招聘到具有培养价值的,也更喜欢能快速打怪升级的,也更愿意让这样的人承担更大的职责。
好的算法搭配上合适的数据结构,可以让代码功能大大的提升效率。当然,算法学习不只是刷题,还需要落地与应用,否则到了写代码的时候,还是会for循环+ifelse。 当开发一个稍微复杂点的业务流程时,往往要用到与之契合的数据结构和算法逻辑,在与设计模式结合,这样既能让你的写出具有高性能的代码,也能让这些代码具备良好的扩展性。
很多时候,你额外的能力才是自身价值的体现,不要以为你的能力就只是做个业务开发每天CRUD,并不是产品让你写CRUD,而是因为你的能力只能产品功能设计成CRUD。 就像数据结构、算法逻辑、源码技能,它都是可以为你的业务开发赋能的,也是写出更好、更易扩展程序的根基,所以学好这份知识非常有必要。 本文涉及了较多的代码和实践验证图稿
可能有人觉得这类知识就像「八股文」,学习只是为了应付面试。如果你真的把这些用于支撑其整个语言的根基当八股文学习,那么硬背下来不会有多少收获。理科学习更在乎逻辑,重在是理解基本原理,有了原理基础就复用这样的技术运用到实际的业务开发。 那么,你什么时候会用到这样的技术呢?就是,当你考虑体量、夯实服务、琢磨性能时,就会逐渐的深入到数据结构以及核心的基本原理当中,那里的每一分深入,都会让整个服务性能成指数的提升。 二、面试题
红黑树的结构和设计都非常优秀,也同样在实现上有着复杂的处理逻辑,包括插入或者删除节点时;颜色变化、旋转操作等操作。但如果只把这些知识点硬背下来,什么时候染色、什么时候旋转,是没有多大意义的,用不了多久也就忘记了。「所以这部分的学习,了解其根本更重要。」
这一章节是结合HashMap的延展,在Jdk1.8中HashMap是使用桶数组+链表和红黑树实现,所以顺着上一章节的核心原理和API功能讲解后,本来这一章节想直接进入到红黑树,但如果想把红黑树学明白,就需要了解他的来龙去脉,也就是它的前身2-3树🌲。
在上一章节我们讲解并用数据验证了,HashMap中的,散列表的实现、扰动函数、负载因子以及扩容拆分等核心知识点以及相应的作用。 除了以上这些知识点外,HashMap还有基本的数据功能;存储、删除、获取、遍历,在这些功能中经常会听到链表、红黑树、之间转换等功能。而红黑树是在jdk1.8引入到HashMap中解决链表过长问题的,简单说当链表长度>=8时,将链表转换为红黑树(当然这里还有一个扩容的知识点,不一定都会树化[MIN_TREEIFY_CAPACITY])。
HashMap 最早出现在 JDK 1.2中,底层基于散列算法实现。HashMap 允许 null 键和 null 值,在计算哈键的哈希值时,null 键哈希值为 0。HashMap 并不保证键值对的顺序,这意味着在进行某些操作后,键值对的顺序可能会发生变化。另外,需要注意的是,HashMap 是非线程安全类,在多线程环境下可能会存在问题。
在面经手册的前两篇介绍了「《面试官都问我啥》」和「《认知自己的技术栈盲区》」,这两篇内容主要为了说明面试过程的考查范围,包括个人的自我介绍、技术栈积累、项目经验等,以及在技术栈盲区篇章中介绍了一个整套技术栈在系统架构用的应用,以此全方面的扫描自己有哪些盲区还需要补充。而接下来的章节会以各个系列的技术栈中遇到的面试题作为切入点,讲解技术要点,了解技术原理,包括;数据结构、数据算法、技术栈、框架等进行逐步展开学习。
讲到技术盲区,先说说我自己。几年前我也是从传统行业跨到互联网,同时还是从C#开发转到Java开发,与其说转不如说是回归Java。从上大学到毕业实习,我都是做Java的,但入职第一家公司,由于技术积累以及需要用C#与中继器、IO板卡、摄像头等进行交互,以及开发的软件是部署到客户端的,所以整套服务都是C#与少部分的C语言进行编写。
实现不了,有时候是功能复杂度较高难以实现,有时候是工期较短实现不完。而编码的行为又是一个不太好量化的过程,同样一个功能每个人的实现方式不一样,遇到开发问题解决问题的速度也不一样。除此之外还很不好给产品解释具体为什么要这个工期时间,这就像盖楼的图纸最终要多少水泥砂浆一样。那么这时研发会尽可能的去通过一些经验,制定流程规范、设计、开发、评审等,确定一个可以完成的时间范围,又避免风险的时间点后。再被压缩,往往会出一些矛盾点,能压缩要解释为什么之前要那么多时间,不能压缩又有各方不断施加的压力。因此有时候不一定是借口,是要考虑如何让整个团队健康的发展。
可能很多小伙伴认为技术开发就是承接下产品需求,写写CRUD,不会的百度一下,就完事了,总觉得别人问的东西像再造火箭一样。但在高体量、高并发的业务场景下,每一次的压测优化,性能提升,都像在研究一道数学题一样,反复的锤炼,压榨性能。不断的深究,找到最合适的设计。除了这些优化提升外,还有那么广阔的技术体系栈,都可能因为你只是注重CRUD而被忽略;字节码编程、领域驱动设计架构、代理模式中间件开发、JVM虚拟机实现原理等等。
工作内容往往有些像在工厂🏭拧螺丝,大部分内容是重复的,也可以想象过去的一年你有过多少创新和学习了新的技能。那么这时候一般为了多学些内容会买一些技术书籍,但!技术类书籍和其他书籍不同,只要不去用看了也就只是轻描淡写,很难接纳和理解。就像设计模式,虽然可能看了几遍,但是在实际编码中仍然很少会用,大部分原因还是没有认认真真的跟着实操。事必躬亲才是学习编程的最好是方式。
设计模式是解决程序中不合理、不易于扩展、不易于维护的问题,也是干掉大部分ifelse的利器,在我们常用的框架中基本都会用到大量的设计模式来构建组件,这样也能方便框架的升级和功能的扩展。但!如果不能合理的设计以及乱用设计模式,会导致整个编程变得更加复杂难维护,也就是我们常说的;反设计、过渡设计。而这部分设计能力也是从实践的项目中获取的经验,不断的改造优化摸索出的最合理的方式,应对当前的服务体量。
两个本想描述一样的意思的词,只因一字只差就让人觉得一个是好牛,一个好搞笑。往往我们去开发编程写代码时也经常将一些不恰当的用法用于业务需求实现中,但却不能意识到。一方面是由于编码不多缺少较大型项目的实践,另一方面是不思进取的总在以完成需求为目标缺少精益求精的工匠精神。
往往很多大需求都是通过增删改查堆出来的,今天要一个需求if一下,明天加个内容else扩展一下。日积月累需求也就越来越大,扩展和维护的成本也就越来越高。往往大部分研发是不具备产品思维和整体业务需求导向的,总以为写好代码完成功能即可。但这样的不考虑扩展性的实现,很难让后续的需求都快速迭代,久而久之就会被陷入恶性循环,每天都有bug要改。
设计模式是可以帮助你改善代码 很多时候你写出来的ifelse都是没有考虑使用设计模式优化,就像;同类服务的不同接口适配包装、同类物料不同组合的建造、多种奖品组合的营销工厂等等。它们都可以让你代码中原本使用if判断的地方,变成一组组类和面向对象的实现过程。 怎么把设计模式和实际开发结合起来
框架中不仅用到设计模式还用了很多,而且有些时候根本不是一个模式的单独使用,而是多种设计模式的综合运用。与大部分小伙伴平时开发的CRUD可就不一样了,如果都是if语句从上到下,也就算得不上什么框架了。就像你到Spring的源码中搜关键字Adapter,就会出现很多实现类,例如;UserCredentialsDataSourceAdapter。而这种设计模式就是我们本文要介绍的适配器模式。
在本次编写的「重学 Java 设计模式」的编写中尽可能多的用各种场景案例还介绍设计的使用,包括我们已经使用过的场景;各种类型奖品发放、多套Redis缓存集群升级、装修公司报价清单和百份考卷题目与答案乱序,通过这些场景案例的实践感受设计模式的思想。但这些场景都是作者通过经验分离出来的,还并不是读者的知识,所以你如果希望可以融会贯通的掌握那么一定要亲力亲为的操作,事必躬亲的完成。 书不是看的是用的
常你也付出了很多的时间,但就是没有得到多少收益。就像有时候很多小伙伴问我,我是该怎么学一个我没接触过的内容。我的个人经验非常建议,先不要学太多理论性的内容,而是尝试实际操作下,把要学的内容做一些Demo案例出来。这有点像你买了个自行车是先拆了学学怎么个原理,还是先骑几圈呢?哪怕摔了跟头,但那都是必须经历后留下的经验。
一个项目的上线往往要经历业务需求、产品设计、研发实现、测试验证、上线部署到正式开量,而这其中对研发非常重要的一换就是研发实现的过程,又可以包括为;架构选型、功能设计、设计评审、代码实现、代码评审、单测覆盖率检查、编写文档、提交测试。所以在一些流程规范下,其实很难让你随意开发代码。 开发代码的过程不是炫技,就像盖房子如果不按照图纸来修建,回首就在山墙上搭一个厨房卫浴!可能在现实场景中这很荒唐,但在功能开发中却总有这样的代码。
在学习的过程中首先要有案例,之后再结合案例与自己实际的业务,尝试重构改造,慢慢体会其中的感受,从而也就学会了如果搭建出优秀的代码。
本设计模式专题系列开始,会带着你使用设计模式的思想去优化代码。从而学习设计模式的心得并融入给自己。当然这里还需要多加练习,一定是人车合一,才能站在设计模式的基础上构建出更加合理的代码。
截至到本章节关于字节码框架 Byte-buddy 的大部分常用 API 的使用已经通过案例介绍比较全面了,接下来介绍关于如何去实现一个抽象类以及创建出相应注解(包括类的注解和方法的注解)的知识点。而注解的这部分内容在一些监控或者拦截处理的场景下还是比较常用的,所以在这章节我们会通过一个例子来创建出含有自定义注解的类和方法。 如果你已经阅读了之前的系列文章,这部分学习的内容并不会有太多的陌生,主要是关于委托(MethodDelegation)方法的使用以及补充自定义注解。
在前面的ASM、Javassist 章节中也有陆续实现过获取方法的出入参信息,但实现的方式还是偏向于字节码控制,尤其ASM,更是需要使用到字节码指令将入参信息压栈操作保存到局部变量用于输出,在这个过程中需要深入了解Java虚拟机规范,否则很不好完成这一项的开发。但!ASM也是性能最牛的。其他的字节码编程框架都是基于它所开发的。
相对于小傅哥之前编写的字节码编程;ASM、Javassist 系列,Byte Buddy 玩法上更加高级,你可以完全不需要了解一个类和方法块是如何通过 指令码 LDC、LOAD、STORE、IRETURN... 生成出来的。就像它的官网介绍; Byte Buddy 是一个代码生成和操作库,用于在 Java 应用程序运行时创建和修改 Java 类,而无需编译器的帮助。除了 Java 类库附带的代码生成实用程序外,Byte Buddy 还允许创建任意类,并且不限于实现用于创建运行时代理的接口。此外,Byte Buddy 提供了一种方便的 API,可以使用 Java 代理或在构建过程中手动更改类。
到本章为止已经写了四篇关于字节码编程的内容,涉及了大部分的API方法。整体来说对 Javassist 已经有一个基本的使用认知。那么在 Javassist 中不仅提供了高级 API 用于创建和修改类、方法,还提供了低级 API 控制字节码指令的方式进行操作类、方法。
字节码编程插桩这种技术常与 Javaagent 技术结合用在系统的非入侵监控中,这样就可以替代在方法中进行硬编码操作。比如,你需要监控一个方法,包括;方法信息、执行耗时、出入参数、执行链路以及异常等。那么就非常适合使用这样的技术手段进行处理。 为了能让这部分最核心的内容体现出来,本文会只使用 Javassist 技术对一段方法字节码进行插桩操作,最终输出这段方法的执行信息,
在上一篇 「Helloworld」 中,我们初步尝试使用了 Javassist字节编程的方式,来创建我们的方法体并通过反射调用运行了结果。大致了解到创建在使用字节码编程的时候基本离不开三个核心类;ClassPool、CtClass、CtMethod,它们分别管理着对象容器、类和方法。但是我们还少用一样就是字段;CtFields,在这一章节中我们不止会使用字段,还会创建多个不同入参类型和返回值的学习。
在字节码编程方面有三个比较常见的框架;ASM、byte-buddy、Javassist,他们都可以对这字节码进行操作,只是操作方式和控制粒度不同。 其中 「ASM」 更偏向于底层,需要了解 「JVM」 虚拟机中指定规范以及对局部变量以及操作数栈的知识。虽然在编写起来比较麻烦,但是它也是性能最好功能最强的字节码操作框架。常见的会用在 「CGLIB」 动态代理类中,以及一些非入侵的探针监控场景中。 另外两个框架都是有强大的 API,操作使用上更加容易控制。虽然对对比上会比 「ASM」 性能差一些,但不是说性能完全不好。同样在一些监控场景中也用的非常多。如果你细心可以在你的工程 「jar」 包搜索一
最简单粗暴的可能就是硬编码在方法中,收取执行耗时以及出入参和异常信息。但这样的成本实在太大,而且有一些不可预估的风险。 可以选择切面方式做一套统一监控的组件,相对来说还是好一些的。但也需要硬编码,同时维护成本不低。 市面上对于这样的监控其实是有整套的非入侵监控方案的,比如;Google Dapper、Zipkin等都可以实现,他们都是基于探针技术非入侵的采用字节码增强的方式进行监控。
研发代码涉及流程链路展示、每个链路测试次数、通过次数、失败次数、当时的出入参信息以及对应的代码块在当前提测分支修改记录等各项信息。最终测试在执行验证时候,分配验证渠道扫描到所有分支节点,可以清晰的看到全链路的影响。那么,这样的测试才是可以保证系统的整体质量的。
随着项目需求的变化,或者说从小公司跳槽了互联网。需求变化了、承载的用户体量增多了,整体系统的架构也随着改变了。就像你做毕业设计的时候,可能只为了完成功能即可,一个单体的MVC结构足可以让你毕业。但!现在你长大了,为了可以承载几百、几千、几亿的用户体量,你开始发现原来还有这么多套路在里面。对于爱学习的人,肯定蠢蠢欲动的想研究研究了
在实际的业务开发中按照不同的场景需要,会有不同的业务架构也就同时会有不同的技术框架来支撑。那么这个专题想把一些常用的框架整理下,方便平时使用的同时也做一些技术沉淀。那么本章节会先搭建一个比较适合个人项目或者一些小公司开发项目的单体架构模型
在Java中动态代理是非常重要也是非常有用的一个技术点,如果没有动态代理技术几乎也就不会有各种优秀框架的出现,包括Spring。 其实在动态代理的使用中,除了我们平时用的Spring还有很多中间件和服务都用了动态代理
Spring Boot + 领域驱动设计使得微服务越来越火热,而随着微服务越来越多,服务的治理就显得尤为重要。 在我们的业务领域开发中,经常会有一些通用性功能搭建,比如;白名单、黑名单、限流、熔断等,为了更好的开发业务功能,我们需要将非业务功能的通用逻辑提取出来开发出通用组件,以便于业务系统使用。而不至于Copy来Copy去,让代码乱的得加薪才能修改的地步!
在实际的业务开发中不只是将路由配置放到文件中,而是需要进行动态管理并且可以在变化时不用重启系统就可以更新。与此同时还需要在接口访问的时候,可以增加一些权限验证以防止恶意访问。
为什么会有路由层?因为在微服务架构设计中,往往并不会直接将服务暴漏给调用端,而是通过调用路由层进行业务隔离,以达到不同的业务调用对应的服务模块。
在微服务架构中,为了更方便的向微服务实例广播消息,我们通常会构建一个消息中心,让所有的服务实例都连接上来,而该消息中心所发布的消息都会被微服务实例监听和消费,我们把这种机制叫做消息总线(SpringCloud Bus)
在实际开发中经常会有一个叫做配置中心的服务,这个服务经过变更参数来动态刷新线上业务数据行为配置。比如;行为开关、活动数据、黑白名单、本地/预发/线上环境切换等等,这些配置信息往往需要在我们不重启系统的时候就可以被更新执行。那么我们一般会使用具备此类属性在分布式系统中适合的组件进行开发配置中心,像是zookeeper、redis发布订阅、或者http定时轮许拉取,他们都可以做成统一配置中心服务。而在Spring Cloud Config 中,默认采用 Git 来存储配置信息,所以使用 Spring Cloud Config 构建的配置服务器,天然就支持对微服务应用配置信息的版本管理,在加上Git
Hystrix Dashboard 可以定时收集接口调用信息;时长、次数、性能、熔断等各项指标来进行监控展示,但是我们每次监控都需要输入一个Hystrix 的链接例如:http://localhost:9001/actuator/hystrix.stream,但是这样并不利于我们去做整体服务的监控,并且在实际使用的过程中如果是几十到几百个接口那么这样的监控几乎达不到监控效果,就累死在监控路上了。因此我们需要使用到 Turbine 来进行监控信息聚合,可以按业务组定义配置方便监控。
Hystrix Dashboard | 断路器仪表盘,Hystrix 依赖服务一段时间窗内的请求调用情况来判断并操作断路器的链接和熔断状态保护系统快速失败服务降级,而这些请求情况的指标信息都是 HystrixCommand 和 HystrixObservableCommand 服务实例在执行过程中记录的重要指标信息,它们除了 Hystrix 断路器实现中使用之外,对于系统运维也有非常大的帮助。这些指标信息会以 “滚动时间窗” 与 “桶” 结合的方式进行汇总,并在内存中驻留一段时间,以供内部或外部进行查询使用,Hystrix Dashboard 就是这些指标内容的消费者之一。