封装对于集成电路来讲是最主要的工具，先进的封装方法可以显着地帮助提高IC性能。了不起的是，这些技术中有许多已经足够成熟，而且已经存在足够长的时间，现在甚至连初创公司和大学都可以使用它们。     虽然这些技术中已经被代工厂所采纳，但最新最有前途的一项技术——chiplets，还不成熟。英特尔的Ramune Nagisetty表示，对于提高技术水平，目前最缺的是在先进封装中混合和匹配硅元件创造更标准化的接口。这样做的目的可以降低在这个生态系统中发挥作用的障碍。   英特尔技术开发部流程和产品集成总监Nagisetty是英特尔的封装专家;英特尔作为美国先进半导体工艺技术的最后堡垒之一，他们认为先进的封装技术将作为未来发展的关键技术之一。Nagisetty表示，英特尔对其每一个封装载体都有一个技术路线图，就像它一直对工艺技术有路线图一样。   封装一直是半导体行业没有多大吸引人的领域，但大约15年前，它开始走向舞台，封装技术可能成为一个性能瓶颈，但只要稍加创新，不仅可以避免这个瓶颈，而且新的封装方法可以提高IC性能。   英特尔这样做已经有一段时间了。据Nagisetty介绍，为了提供异构芯片的高密度互连，英特尔在2008年提出了嵌入式多芯片互连桥接技术(EMIB)技术。   EMIB是2.5D技术的一个变种。2.5D封装的常用方法是使用硅中介层，它是夹在两片芯片之间的一层带孔的硅。英特尔认为中介层有些太大，所以它的EMIB使用了一个有多个路由层的桥接器。   Nagisetty：“新技术在开始使用之前需要一个临界点，”转折点是基于神经网络的人工智能架构。 “这是很重要的一点——它显示了神经网络的可行性，并且在封装内产生了加速器和高带宽内存——这为将内存嵌入封装内奠定了根基。”   英特尔于2014年首度发表EMIB，表示该技术是2.5D封装的低成本替代方案   如今在传统半导体工艺微缩技术变得越来越复杂且昂贵的此刻，像EMIB这样能实现高性能芯片组的低成本、高密度封装技术日益重要。台积电(TSMC)所开发的整合型扇出技术(InFO)也是其中一种方案，已被应用于苹果(Apple) iPhone的A系列处理器。   英特尔一直将EMIB幕后技术列为“秘方”，包括所采用的设备以及在芯片之间打造简化桥接的方法；不过该公司打算将AIB变成一种任何封装技术都能使用、连接“小芯片”的标准接口，以催生一个能支持自家产品的零件生态系统。   从历史上看，半导体行业的总体发展将越来越多的功能集成到芯片上，但对于一些先进集成电路设计来说，这或许是不可能的。   首先，一个公司不可能把一些应用程序所需的所有电路放在一个巨大的模具上，从生产的角度来看，模具的尺寸是有限的。   Nagisetty指出:“推动这一趋势的第二点是，重复使用的设计成本不断上升，以及特定技术节点对IP可移植性的需求。”无论是针对移动设备还是高性能，逻辑技术正变得越来越专业化，在先进集成电路设计中，几乎不需要在相同的技术节点上实现SerDes。更重要的是，有可能将某一项技术(例如SerDes)定制为一个技术节点。   Nagisetty引用了Intel Stratix FPGA的例子：有一个Stratix FPGA菜单，在六个不同的技术节点上执行，可从三个不同的工厂获得。“我认为Stratix是第一个达到每秒58千兆字节的产品。”“它使我们更具竞争力，并率先以高速SerDes进入市场。”   使用高级封装的第三个原因是获得敏捷性和灵活性。“对于不同技术，chiplets在混合和匹配的价值正变得越来越明显。”   Nagisetty表示，英特尔的Kaby Lake G和Lakefield产品就是两个很好的例子。     通过Kaby Lake G，我们将第三方IP整合到我们的封装中，我们能够为高性能手机游戏创造一个更小的形式。这里的第三方IP指的就是AMD的Radeon加速器。   这是利用先进封装提高最终使用性能的一个明显例子。   Intel和AMD虽说是死对头，但是去年双方竟然意外合体，合作推出了Kaby Lake-G系列处理器，Kaby Lake G使用英特尔的EMIB 2.5D方法，而Lakefield则依靠die堆叠- 3D堆叠。英特尔称其3D堆叠系统为Foveros。它使用Intel的CPU搭配AMD的Radeon显卡及HBM2显存，图形性能非常亮眼。不过Kaby Lake-G的市场化不算成功，现在Intel决定停产这款A/I合作的处理器了。根据Intel发布的通知，Kaby Lake-G系列从10月7日开始退役，2020年1月31日为最后的订单日，2020年7月31日为最后的出货日，之后就完全停产了。     Lakefield是证明了先进封装可以带来最小X-Y引脚。” 用户可以从性能或外形上看到好处。   英特尔开发了一组丰富的封装技术，而且为了使事情更有简单，它们可以混合匹配。例如，英特尔推出的“Co-EMIB”，这是EMIB和Foveros的结合。   2019年，英特尔推出了两种更先进的封装变体，全向互联(ODI)，从架构的角度来看，它是EMIB和Foveros的下一个演进步骤，英特尔能够将多个芯片堆叠在玻璃纤维基板的上方，相互之间的上方；以及基板的压痕和空腔内。ODI由类似EMIB的硅片组成，可以在两个硅片之间实现高密度布线(如GPU和内存堆栈，或SoC和核心逻辑)；以及作为硅片凸点延伸到基板的铜极。它会带来若干好处，包括通过穿硅通孔(tsv)向堆叠中的顶部管芯输送功率。   英特尔、台积电和其他公司正在研究一种被称为铜-铜混合键合的方法，这是堆叠技术的另一种变体，这可能会带来3D IC的创新，并可以将更多的DRAM芯片连接起来，这种组合被称为DRAM cubes。     我们是否有明确的路径来不断改进这些封装技术，就像连续的生产过程节点总是被绘制出来的那样？   Nagisetty：“我们的每一个封装载体都有一个技术路线图，”“所以，我们有一个中介层，它可以降低沟道高度。Foveros将达到25微米。混合键合将从10微米开始，并逐渐降低。”   Kaby Lake G的例子激发了芯片设计者们的梦想，即混合和匹配来自不同供应商的功能，而不仅仅是一个供应商。这是chiplets的关键概念。   从商业角度来看，chiplets方法很有意义。芯片上高度集成的SoC成本可能非常高。此外，这种高度集成的半导体系统的复杂性使制造更具挑战性;较高的复杂性与产量损失有直接关系。   美国国防高级研究计划局(DARPA)正在支持一项计划，以推动chiplets市场。DARPA对这项技术的看法是:   由于初始原型成本高和对替代材料集的要求等因素，最先进的SoC的整体特性并不总是为国防部(DoD)或其他小体积应用所接受。为了增强下一代产品的整体系统灵活性和减少设计时间，微电子综合常用功能整合及微电子知识产权产品重新优化利用计划(简称CHIPS)寻求在IP重用中建立一个新的范例。   CHIPS 项目的主要目标，是开发出全新的技术框架，将如今电子产品中插满芯片的电路板压缩成为尺寸小得多的集成“微芯片零件组”。这种框架会将受知识产权保护的微电子模块与其功能整合成“微芯片零件”。这些微芯片零件能够实现数据存储、信号处理和数据处理等功能，并可以随意相连，如拼图一样拼成“微芯片零件组”。     CHIPS项目有望催生更多新技术产品，如更小的集成电路板替代品，要求高速数据转换和强大处理性能紧密结合的高带宽射频系统，通过整合各种处理以及加速功能的 “微芯片零件”，还可以得到能够从大量杂乱数据中过滤出可用数据指令的快速机器学习系统。   与更复杂的SoC相比，使用chiplets可以显著降低成本。这张图是AMD的Lisa Su在2017年IEDM会议上发表的一篇论文中展示的，并被开放计算项目复制。   美国芯片法案确实专门为高级封装研究进行了资助，但它没有特别提到DARPA的芯片计划。   Nagisetty介绍，英特尔当然参与了DARPA的芯片计划。“Stratix FPGA是这方面的核心。”   CHIPS成功的关键总体来说是chiplets技术，它将创造更标准化的接口，这样其他公司的芯片就可以连接起来。     开发通用接口是一项艰巨的任务，因为要考虑许多因素，并且并非所有应用程序都必须以相同的方式权衡利弊。接口技术中要考虑的一些因素是成本，面积，每位能量，带宽，等待时间，距离，可伸缩性以及在不同过程节点中实现的能力。幸运的是，在DARPA的支持下，英特尔已经使其高性能的高级接口总线（AIB）用于通过git-hub的开源框架公开免费地连接小芯片。该接口可提供任何竞争解决方案中最高的带宽和最低的每位功率，并实现接近单片的互连性能。英特尔多年来一直在生产带有该接口的产品，目前在Stratix 10 FPGA系列上提供该产品，以将chiplets连接到FPGA架构。随着英特尔在业界的影响力以及正在采用的新兴财团，AIB有望成为chiplets互连标准。 Nagisetty：“我相信它将发展成为一个生态系统，创新将被开启，它类似于开发电路板的方式——那里有像PCI Express这样的东西——允许公司基于一个接口标准来构建产品。”   早期,有很多的复杂性,以及商业模式需要解决,”她继续说道,“但是我喜欢,人们可以参与这个生态系统。以前，屏障非常高。但现在，有一些初创企业和大学参与进来。”   但Nagisetty表示，如果一个组织能够对于chiplets技术的标准创建进行指导，那将会大有裨益。开放计算项目(OCP)是一个尝试填补这一空白的组织，其中他们提议的ODSA项目旨在在小芯片之间创建一个开放的接口，以便可以将多个供应商的同类最佳小芯片组合在一起以创建定制产品。 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

大家好，先简单做个自我介绍，我是非科班出身，通过自学的方式，拿到了BATTMD多家和微软offer。今天给大家分享一下自己的算法的经验。 写在前面 随着互联网的发展，各大厂的招聘要求水涨船高，几年前，做算法题还不是必备项，有的公司最多要求写个链表插入，二叉树遍历这种课本上的模板题。但如今由于投身互联网的人太多，国内公司也向硅谷大厂招聘看齐，推行了代码考察。按形式来讲，代码考察的难度和广度可能还会随着时间增长。因此，掌握算法能力不仅仅是外企所需，更是拿到国内互联网厂的基本功。 但很多同学开始接触算法的时候直接硬刷，通过做题学习知识点，虽然这不失为一种学习方法，但是这种方法往往效率偏低，而且学习的知识点偏琐碎，比较难形成一个体系。由于本人非科班，学习算法也算是从零开始，这里分享一下自己在算法学习的路径，给大家做个参考。 第一阶段（1-2个月） 掌握一门面向对象语言，能熟悉它的语法规则和常用包。以java为例，java是一门面向对象的程序语言，我在这阶段做的工作有： 找一本市面上好评较多的教材熟悉语法规则，这里我用的是《疯狂java讲义》。 下载 IDE对着敲一下，巩固自己对语言的书写。 在这一部分，很多人就会在意语言的选择，有的程序员说php是世界上最好的语言，又有人说人生苦短，我用 Python 。有人学了 C++，又去学了 Python , Go 语言，陷入了语言的学习不能自拔。在这里我给出自己的一个建议：只要是面向对象语言，针对算法来说，学一门足以。 你也可以选择小众语言 Go, Rust…只要工具包多，教程多都可以，关键是多练习，熟悉这门语言的语法规则。这是这阶段最重要的。 第二阶段（1-2个月） 熟悉常见数据结构，并且熟悉这个数据结构在你的语言中的使用规则。以java为例，相当多的数据结构在Java的collection框架下，我在这个阶段做的工作有： 找一个市面上较好的教程入门，这里我采用的是慕课网《算法与数据结构-综合提升 C++版》视频，由于他采用的语言是C++，我在他的基础上对照着写了个Java版本。 了解自己熟悉语言的常见数据结构使用，包括了解二叉树，字典树，哈希表，集合，并查集等等的基本概念。 这阶段，重点在数据结构的学习，重点掌握的数据结构有：链表、哈希表、集合、栈、队列、堆、二叉树、二叉搜索树、图。 这部分需要做到时间空间复杂度，性质，了如指掌。其次掌握并查集、字典树，这部分会写就行。最后稍作了解B树，B+树，红黑树，AVL树。了解部分的话，知道他们的定义和概念即可。 第三阶段（1个月左右） 熟悉常见的算法，如 DFS 、 BFS 、 DP 、排序等等，并在你使用的语言中加以练习。在前两阶段的学习中，我们已经熟悉了语言语法规则，常见数据结构，为后续的算法打下了基础。以java为例，我采用的学习方法是： 找一本算法书入门，这里推荐 Robert Sedgewick 写的《算法（第四版）》这本书实现语言是 Java 。 找一个系统性的视频，进行学习，这里推荐《算法（第四版）》配套视频， coursera 上可看， Bilibili 有搬运版本。 这阶段，很多知识点会在第二部分学过了。所以这部分的重点在于针对各个算法有一个系统性，体系性的了解。 如果大家不喜欢《算法（第四版）》的风格，推荐大家看一下《大话数据结构与算法》。其中《算法（第四版）》课后题大家可以不做，对他讲述的内容理解即可。 第四阶段（1-2个月） 在前三个阶段的学习中，我们了解了常见的数据结构和算法，并针对算法进行了系统学习，接下来就可以开始我们的刷题之旅了。这里推荐的资料有： 慕课网 liuyubobobo 《玩转算法面试– Leetcode真题分门别类讲解》针对他所列举的例题和作业题，进行练习。 这一阶段，我们终于进入了刷题环节，大家记得注册 leetcode 力扣网账户，然后开始自己的刷题之旅吧！ 第五阶段（2-3个月） 这一阶段希望大家多刷题，达到见多识广的地步。这里推荐两本书： 《剑指offer》这本书大名鼎鼎，不用多说。这些题在leetcode网站上可刷。 《程序员代码面试指南》这本书罗列的题目也很不错，牛客网可刷。 这个阶段希望大家多做题，多见新题。 这样的话在见新题的过程中做个整理，慢慢的，大家就会发现很多题就是新瓶装旧酒了。 这一阶段的目的是熟能生巧，多刷好题，经典题。这里推荐的题是： leetcode hot 100，hot100 leetcode 精选top面试题 《剑指offer》 这阶段的关键点在于多刷，刷遍数。 这个就像背单词一样，多做几遍，对常见题的理解和他的衍生题，都会有一个烂熟于心的程度。针对我这边列举的题单，做到见题目，秒想思路。但是大家也不用太苛求，有几个hard题的corner case比较难写，大家思路对就行。 进阶高级算法。这部分其实如果不是面试 Google 这种公司，完成第六阶段的学习就ok了。如果还想继续精进，可以参考书籍： 《挑战程序设计竞赛》这本书极好，无论是列举的习题还是例题都值得反复玩味。 各大OJ平台刷题。 各大神在完成这阶段的学习，可以去打打程序设计竞赛了。 学习算法关键是坚持，按这套流程走下来，相信大家能顺利通过各大厂互联网笔试了。我个人在 leetcode 上做的题一共是450题，算上二刷，三刷的题一共1k+左右，虽然看起来数字挺多，其实按每天三题算，也就一年而已。无论是校招小伙伴还是社招的朋友，坚持刷题，总会有收获。祝大家早日拿到理想的Offer! 哈喽，我是小林，就爱图解计算机基础，如果觉得文章对你有帮助，欢迎分享给你的朋友，也给小林点个「在看」，这对小林非常重要，谢谢你们，给各位小姐姐小哥哥们抱拳了，我们下次见！ 读者问：小林你能分享做公众号的经验吗？ 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

众所周知，三星旗舰手机一般会采用两种不同的处理器规格，在美国市场以及中国市场采用高通制造的芯片，而其它地区(包括中东和欧洲)则采用三星自家的Exynos处理器。 据报道，高通骁龙875和三星Exynos 2100都使用了5nm工艺制程，而且两颗芯片都有超大核(ARM Cortex X1)、大核(ARM Cortex A78)和小核，采用“1+3+4”三丛集架构。 前段时间，三星正式推出了Exynos 1080芯片组，这是该品牌首款基于5nm工艺的SoC，大大提高了设备的电源效率和性能。泄漏的基准测试结果表明，它比高通Snapdragon 865强大。 至于图形性能上，两款处理器则有着不同的规格，三星 Exynos 2100可能会配备Mali-G78 GPU，而高通Snapdragon 875可能会配备自研设计的Adreno 660 GPU。尽管图形性能可以与之媲美，但高通在这方面仍将保持领先地位。 报道指出，Exynos 2100和骁龙875的CPU频率有所区别，其中骁龙875超大核主频为2.84GHz，大核主频为2.42GHz，小核主频为1.8GHz。 Exynos 2100超大核主频为2.91GHz，大核主频为2.81GHz，小核主频为2.21GHz。 从曝光的信息来看，Exynos 2100的超大核、大核和小核的CPU频率都超过了骁龙875，但这是否意味着Exynos 2100版三星Galaxy S21系列会消耗更多的电量? 作为一款定位高端旗舰的手机芯片，Exynos 2100和骁龙875一样具有强悍的性能。另外，预计Exynos 2100和Snapdragon 875还具有相同的核心配置，大家对此还有哪些进一步的看法呢?欢迎留言讨论哦!

JDK 是什么？ JDK 是用于支持 Java 程序开发的最小环境。 Java 程序设计语言 Java 虚拟机 Java API类库 JRE 是什么？ JRE 是支持 Java 程序运行的标准环境。 Java SE API 子集 Java 虚拟机 Java历史版本的特性？ Java Version SE 5.0 引入泛型； 增强循环，可以使用迭代方式； 自动装箱与自动拆箱； 类型安全的枚举； 可变参数； 静态引入； 元数据（注解）； 引入Instrumentation。 Java Version SE 6 支持脚本语言； 引入JDBC 4.0 API； 引入Java Compiler API； 可插拔注解； 增加对Native PKI(Public Key Infrastructure)、Java GSS(Generic Security  Service)、Kerberos和LDAP(Lightweight Directory Access Protocol)的支持； 继承Web Services； 做了很多优化。 Java Version SE 7 switch语句块中允许以字符串作为分支条件； 在创建泛型对象时应用类型推断； 在一个语句块中捕获多种异常； 支持动态语言； 支持try-with-resources； 引入Java NIO.2开发包； 数值类型可以用2进制字符串表示，并且可以在字符串表示中添加下划线； 钻石型语法； null值的自动处理。 Java 8 函数式接口 Lambda表达式 Stream API 接口的增强 时间日期增强API 重复注解与类型注解 默认方法与静态方法 Optional 容器类 运行时数据区域包括哪些？ 程序计数器 Java 虚拟机栈 本地方法栈 Java 堆 方法区 运行时常量池 直接内存 程序计数器（线程私有） 程序计数器（Program Counter Register）是一块较小的内存空间，可以看作是当前线程所执行字节码的行号指示器。分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器完成。 由于 Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式实现的。为了线程切换后能恢复到正确的执行位置，每条线程都需要一个独立的程序计数器，各线程之间的计数器互不影响，独立存储。 如果线程正在执行的是一个 Java 方法，计数器记录的是正在执行的虚拟机字节码指令的地址； 如果正在执行的是 Native 方法，这个计数器的值为空。 程序计数器是唯一一个没有规定任何 OutOfMemoryError 的区域。 Java 虚拟机栈（线程私有） Java 虚拟机栈（Java Virtual Machine…

一位七牛的资深架构师曾经说过这样一句话： “ Nginx+业务逻辑层+数据库+缓存层+消息队列，这种模型几乎能适配绝大部分的业务场景。 这么多年过去了，这句话或深或浅地影响了我的技术选择，以至于后来我花了很多时间去重点学习缓存相关的技术。 我在10年前开始使用缓存，从本地缓存、到分布式缓存、再到多级缓存，踩过很多坑。下面我结合自己使用缓存的历程，谈谈我对缓存的认识。 01 本地缓存 1. 页面级缓存 我使用缓存的时间很早，2010年左右使用过 OSCache，当时主要用在 JSP 页面中用于实现页面级缓存。伪代码类似这样： "foobar" scope= "session">        some jsp content  中间的那段 JSP 代码将会以 key=”foobar” 缓存在 session 中，这样其他页面就能共享这段缓存内容。 在使用 JSP 这种远古技术的场景下，通过引入 OSCache 之后 ，页面的加载速度确实提升很快。 但随着前后端分离以及分布式缓存的兴起，服务端的页面级缓存已经很少使用了。但是在前端领域，页面级缓存仍然很流行。 2. 对象缓存 2011年左右，开源中国的红薯哥写了很多篇关于缓存的文章。他提到：开源中国每天百万的动态请求，只用 1 台 4 Core 8G 的服务器就扛住了，得益于缓存框架 Ehcache。 这让我非常神往，一个简单的框架竟能将单机性能做到如此这般，让我欲欲跃试。于是，我参考红薯哥的示例代码，在公司的余额提现服务上第一次使用了 Ehcache。 逻辑也很简单，就是将成功或者失败状态的订单缓存起来，这样下次查询的时候，不用再查询支付宝服务了。伪代码类似这样： 添加缓存之后，优化的效果很明显 , 任务耗时从原来的40分钟减少到了5~10分钟。 上面这个示例就是典型的「对象缓存」，它是本地缓存最常见的应用场景。相比页面缓存，它的粒度更细、更灵活，常用来缓存很少变化的数据，比如：全局配置、状态已完结的订单等，用于提升整体的查询速度。 3. 刷新策略 2018年，我和我的小伙伴自研了配置中心，为了让客户端以最快的速度读取配置， 本地缓存使用了 Guava，整体架构如下图所示： 那本地缓存是如何更新的呢？有两种机制： 客户端启动定时任务，从配置中心拉取数据。 当配置中心有数据变化时，主动推送给客户端。这里我并没有使用websocket，而是使用了 RocketMQ Remoting 通讯框架。 后来我阅读了 Soul 网关的源码，它的本地缓存更新机制如下图所示，共支持 3 种策略： ▍zookeeper watch机制 soul-admin 在启动的时候，会将数据全量写入 zookeeper，后续数据发生变更时，会增量更新 zookeeper 的节点。与此同时，soul-web 会监听配置信息的节点，一旦有信息变更时，会更新本地缓存。 ▍websocket 机制 websocket 和 zookeeper 机制有点类似，当网关与 admin 首次建立好 websocket 连接时，admin 会推送一次全量数据，后续如果配置数据发生变更，则将增量数据通过 websocket 主动推送给 soul-web。 http请求到达服务端后，并不是马上响应，而是利用 Servlet 3.0 的异步机制响应数据。当配置发生变化时，服务端会挨个移除队列中的长轮询请求，告知是哪个 Group 的数据发生了变更，网关收到响应后，再次请求该 Group 的配置数据。 不知道大家发现了没？ pull 模式必不可少 增量推送大同小异 长轮询是一个有意思的话题 , 这种模式在 RocketMQ 的消费者模型也同样被使用，接近准实时，并且可以减少服务端的压力。 02 分布式缓存 关于分布式缓存, memcached 和 Redis 应该是最常用的技术选型。相信程序员朋友都非常熟悉了，我这里分享两个案例。 1.  合理控制对象大小及读取策略 2013年，我服务一家彩票公司，我们的比分直播模块也用到了分布式缓存。当时，遇到了一个 Young GC 频繁的线上问题，通过 jstat 工具排查后，发现新生代每隔两秒就被占满了。 进一步定位分析，原来是某些 key 缓存的…

下面我们就要对不同的协议层进行分类介绍了，我们还是采用自上而下的方式来介绍，这种介绍对读者来说更容易接纳，吸收程度更好。 一般情况下，用户不太在意网络应用程序实际上是按照怎样的机制运行的，但我们是程序员吖，就套用朱伟的一句话说：你觉得计算机网络程序员不了解，你指着互联网用户去了解吗？有内个味儿没？ 应用层指的是 OSI 标准模型的第 5、6、7层，也就是会话层、表现层、应用层。 我们介绍的时候都会使用 OSI 标准模型来介绍，因为这样涵盖的层次比较多，这样对于 TCP/IP 模型来说，你也能加深理解。 应用层概念 应用层协议的定义 现如今，越来越多的应用程序利用网络进行通信，这些应用有 Web 浏览器、远程登录、电子邮件、文件传输、文件下载等，应用层的协议正是进行这些行为活动的规则和标准。 应用层协议(application layer protocol) 定义了在不同端系统上的应用程序进程如何相互传递报文。一般来说，会定义如下内容 交换的报文类型：是请求报文还是相应报文 报文字段的解释：对报文中各个字段的详细描述 报文字段的语义：报文各个字段的含义是什么 进程何时、以什么方式发送报文以及响应 应用层体系结构 应用层体系结构 的英文是 Application Architecture，它指的是应用层的结构，一般来说，应用层有两种主流体系结构 客户 – 服务器体系结构 ( client-server architecture ) 对等体系结构 ( P2P architecture ) 下面我们先来聊一下客户 – 服务器体系结构的概念 在客户-服务器体系结构中，有一个总是打开的主机称为 服务器(Server)，它提供来自于 客户(client) 的服务。我们最常见的服务器就是 Web 服务器，Web 服务器服务于来自 浏览器 的请求。 当 Web 服务器通过浏览器接收到用户请求后，它会经过一系列的处理把信息或者页面等通过浏览器呈现给应用。这种模式就是客户 – 服务器模式。 有两点需要注意 在客户 – 服务器模式下，通常客户彼此之间是并不互相通信的。 服务器通常具有固定的、周知的 IP 地址可以提供访问。 客户 – 服务器模式通常会出现随着客户数量的急剧增加导致单台服务器无法完成大量客户请求的情况。为此，通常需要配备大量主机的 数据中心(data center) ，用来跟踪所有的用户请求。 于此相反，P2P 也就是对等体系结构对这种数据中心的依赖性很低，因为在 P2P 体系结构中，应用程序在两个主机之间直接通信，这些主机被称为对等方，与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能。常见的 P2P 体系结构的应用有 文件共享、视频会议、网络电话等。 P2P 一个最大的特点就是 扩展性(self-scalability)，因为 P2P 网络的一个重要的目标就是让所有的客户端都能提供资源、获取资源，共享带宽，存储空间等。因此，当有更多节点加入且对系统请求增多，整个系统的容量也增大。这是具有一组固定服务器的客户 – 服务器结构不具备的，这也就是 P2P 的扩展性。 进程通信 我们上面说到了两种体系结构，一种是客户 – 服务器模式，一种是 P2P 对等模式。我们都知道一个计算机允许同时运行多个应用程序，在我们看起来这些应用程序好像是同时运行的，那么它们之间是如何通信的呢？ 用操作系统的术语来说，进行通信实际上是 进程(process)而不是程序。一个进程可以被认为是运行在端系统中的程序。当多个进程运行在相同的端系统上时，它们使用进程间的通信机制相互通信。进程间的通信规则由操作系统来确定。 进程与计算机网络之间的接口 计算机是庞大且繁杂的，计算机网络也是，应用程序不可能只有一个进程组成，它同样是多个进程共同作用协商运行，然而，分布在多个端系统之间的进程是如何进行通信的呢？实际上，每个进程之间会有一个 套接字(socket) 的软件接口存在，套接字是应用程序的内部接口，应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。 通过一个实例来简单类比一下套接字和网络进程：进程可类比一座房子，而它的套接字相当于是房子的门，当一个进程想要与其他进程进行通信时，它会把报文推出门外，然后通过运输设备把报文运输到另外一座房子，通过门进入房子内部使用。 下图是一个通过套接字进行通信的流程图 ‍ ‍ ‍ ‍ ‍ ‍ ‍ 从图可以看到，Socket 属于主机或者服务进程的内部接口，由应用程序开发人员进行控制，两台端系统之间进行通信会通过 TCP 的缓冲区经由网络传输到另一个端系统的 TCP 缓冲区，Socket 从 TCP 缓冲区读取报文供应用程序内部使用。 套接字是建立网络应用程序的可编程接口，因此套接字也被称为应用程序和网络之间的 应用程序编程接口(Application Programming…

程序员使用的语言有鄙视链吗？有人说有，有人说没有。一个美团员工发帖说，筛选简历时用go语言的基本不看。短短一句话，把对go语言的鄙视体现得淋漓尽致，难道go语言真的不如其他语言？  和他一样想法的前阿里程序员说，因为用java的人多，简历也多，他们也优先选择用java的程序员。 一个前腾讯程序员说，go语言适合开发一些简单的中间件，但因为没有面向对象，没有工业级的包管理工具，不太适合业务逻辑比较复杂的场景，缺乏抽象与继承，go的项目做大了会非常难以维护。  还有人说go语言比较原始，是专科生语言。 也有人不同意楼主的看法，有人说java都几年了才有几个出圈的项目？go才几年就有这么多出圈项目。在他们c\c++眼里虽然对java不屑一顾，却也没有对一门新语言围追堵截，楼主这么打压go，是不是怕了？  网友说，对go的鄙视就是不愿意接受新鲜事物罢了。 有些网友认为多种语言完全可以搭配使用，有人说自己是搞c++的，下一家也大概率会c++和go语言并用。 有人说java配go不香吗？ 针对go和java之争，有人说java之美是用go的人无法理解的。 有人说go就是辣鸡，越写越恶心，还是java牛X。 有人说用go语言根本找不到工作，应届生别被骗了，java才是天下第一最好找工作的语言，千万别学go了……这话怎么听着味道怪怪的？ 也有人说自己虽然不用go，也很讨厌java八股文。 java和go到底谁更好我们不知道，但是楼主的意思显然是劝大家不要学go。难道是想告诉应届生第一份工作该选java，去美团？ 这下引得一堆求职者纠结死了，有人说自己即将入职腾讯写go，难道要拒了腾讯，去美团写java吗？ 有人说python不好找工作，想换java，朋友说java内卷严重，让他换成go，结果楼主又说学go的不要，那到底要学什么？这确实很难选择啊，谁知道学什么语言才好？ 也有一些网友说了，楼主真是当韭菜还当出优越感了，都是打工人，内卷成这样，瞧这劣根性，人才啊！ 也有人问招程序员还看语言吗？应该在意什么？ 用语言来筛选人才，稍微有点技术追求的人也不会去这种岗位。 但也有人说，如果你相信语言不重要，你就输了。打个比方，鹅厂招cpp的肯定不会看go的简历，但招go的会考虑cpp，语言之间就是有区别。 一个程序员说自己用过2年c语言，9年java，5年go，也用python做过项目。从自身经验出发，劝那些只会皮毛的小伙伴们多多学习各种语言和技术，盲目崇拜或厌恶一种语言是给自己设限，没好处的。 总而言之，脱离应用场景来比较语言是在耍流氓，每个语言都有不同的优势与缺陷。 长按订阅更多精彩▼ 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

不同级别的程序员除了薪资待遇不一样，还有什么其他的差别吗？ 有人说： 连配备 的电脑、桌椅都不 一样！ 美团的专业职级体系从P1-1逐级提高，到P5为最高。一个新入职的美团程序员发帖爆料：mentor告诉他，美团虽然屏蔽职级，但可以通过椅子判断。那些坐人体工学椅的至少都是3-1或者3-2以上的大佬。真是这样吗？ 网友们乐了，按照这个逻辑，可以去看看老大坐的啥椅子，应该是龙椅吧。 再继续推断下去，1-3的员工是不是不配坐椅子？ 应届生更惨了，要自己带椅子才行。 许多美团员工和前美团员工不同意楼主的说法，有人说人体工学椅是靠排队的，得排好几年才能拿到。 有人说自己3-2，没人给发人体工学椅，自费买的。 有人说自己3-3，坐的是小板凳……这句话别有深意，此小板凳非彼小板凳吧？ 大概是因为3-1、3-2其实不算什么大佬，不过是些大头兵，没有好椅子也是正常。 再说，坐着人体工学椅的人也不一定是高级别，许多2-2、2-3的员工也坐上了。 大概是因为很多人是自费买的，通过买椅子把级别提高到3-1，也是一种不错的方法。 美团员工表示自己要去咸鱼买个二手人体工学椅，借此提升一下自己的级别。 那么问题来了，自己买的工学椅跳槽时候怎么办呢？ 长按订阅更多精彩▼ 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

链表和数组是数据类型中两个重要又常用的基础数据类型。 数组是连续存储在内存中的数据结构，因此它的优势是可以通过下标迅速的找到元素的位置，而它的缺点则是在插入和删除元素时会导致大量元素的被迫移动，为了解决和平衡此问题于是就有了链表这种数据类型。 链表和数组可以形成有效的互补，这样我们就可以根据不同的业务场景选择对应的数据类型了。 那么，本文我们就来重点介绍学习一下链表，一是因为它非常重要，二是因为面试必考，先来看本文大纲： 看过某些抗日神剧我们都知道，某些秘密组织为了防止组织的成员被“一窝端”，通常会采用上下级单线联系的方式来保护其他成员，而这种“行为”则是链表的主要特征。 简介 链表（Linked List）是一种常见的基础数据结构，是一种线性表，但是并不会按线性的顺序存储数据，而是在每一个节点里存到下一个节点的指针（Pointer）。 链表是由数据域和指针域两部分组成的，它的组成结构如下： 复杂度分析 由于链表无需按顺序存储，因此链表在插入的时可以达到 O(1) 的复杂度，比顺序表快得多，但是查找一个节点或者访问特定编号的节点则需要 O(n) 的时间，而顺序表插入和查询的时间复杂度分别是 O(log n) 和 O(1)。 优缺点分析 使用链表结构可以克服数组链表需要预先知道数据大小的缺点，链表结构可以充分利用计算机内存空间，实现灵活的内存动态管理。但是链表失去了数组随机读取的优点，同时链表由于增加了结点的指针域，空间开销比较大。 分类 链表通常会分为以下三类： 单向链表 双向链表 循环链表 单循链表 双循环链表 1.单向链表 链表中最简单的一种是单向链表，或叫单链表，它包含两个域，一个数据域和一个指针域，指针域用于指向下一个节点，而最后一个节点则指向一个空值，如下图所示： 单链表的遍历方向单一，只能从链头一直遍历到链尾。它的缺点是当要查询某一个节点的前一个节点时，只能再次从头进行遍历查询，因此效率比较低，而双向链表的出现恰好解决了这个问题。 接下来，我们用代码来实现一下单向链表的节点： private static class Node<E> {    E item;    Node  next;     Node(E element, Node  next) {          this.item = element;          this.next = next;     } } 2.双向链表 双向链表也叫双面链表，它的每个节点由三部分组成：prev 指针指向前置节点，此节点的数据和 next 指针指向后置节点，如下图所示： 接下来，我们用代码来实现一下双向链表的节点： private static class Node<E> {    E item;    Node  next;     Node  prev;     Node(Node  prev, E element, Node  next) {          this.item = element;          this.next = next;          this.prev = prev;     } } 3.循环链表 循环链表又分为单循环链表和双循环链表，也就是将单向链表或双向链表的首尾节点进行连接，这样就实现了单循环链表或双循环链表了，如下图所示： Java中的链表 学习了链表的基础知识之后，我们来思考一个问题：Java 中的链表 LinkedList 是属于哪种类型的链表呢？单向链表还是双向链表？ 要回答这个问题，首先我们要来看 JDK 中的源码，如下所示： package java.util;import java.util.function.Consumer;public class LinkedList<E>    extends AbstractSequentialList<E>    implements List<E>, Deque<E>, Cloneable, java.io.Serializable{ // 链表大小    transient int size = 0;    // 链表头部    transient Node  first;      // 链表尾部      transient Node  last;      public LinkedList() {     }      public LinkedList(Collection  c) {          this();         addAll(c);     }        // 获取头部元素      public E getFirst() {          final Node  f = first;          if (f ==  null)              throw  new NoSuchElementException();          return f.item;     }      // 获取尾部元素      public E getLast() {          final Node  l = last;          if (l ==  null)              throw  new NoSuchElementException();…

背景 高德地图作为日活过亿的国民级出行生活服务平台，承载着海量用户服务的是后台的超大规模集群。从用户角度，如果出问题，影响会很大。3机房异地部署造成线上环境复杂，链路复杂。在这样的条件下，如何避免因故障造成用户的伤害，以及在复杂链路条件下做好容量规划，做好灾备，并在第一时间发现问题，通过流量控制和预案演练做应急响应就显得至关重要，而所有的工作都不能等到事情发生之后才做，我们需要有一种验证手段来做好提前性能摸底，这就是全链路压测，让真实的流量提前到来。 全链路压测作为线上服务稳定性保障的重要手段，对高德来说也是非常重要的。高德全链路压测平台TestPG从无到有，在经历过常态化压测后，已基本可以保障高德的所有全链路压测和日常压测，达到了平台初期快速、准确压测和全链路压测的目标。而语料生产(流量处理)作为全链路压测的重要环节，本文将对此做重点介绍。 一次全链路压测可简单总结为3步：压测前的流量处理（也就是生产语料）、压测中确定压力模型启动压测、压测后的结果分析与问题定位。每次全链路压测，压测前的流量处理是整个压测过程中最耗时的一环。过去往往由运维采集日志交给测试同学写脚本处理，耗时相当严重、成本巨大，且存在请求过期等诸多问题。基于这些问题，高德全链路压测平台TestPG前期已规范了高德压测的语料格式，统一了高德压测的流量处理流程。但随着高德全链路压测的演进，后续面临两个主要问题： 语料生产流程缺乏统一管控。虽然平台前期已规范了语料格式，但各业务只是按照语料规范处理流量，生产流程缺乏统一、标准化管控，导致语料生产成本依然很大。尤其对于全链路压测来说，语料准备是最耗时的环节。 接口级别的精准控压无法满足需求。高德作为国民级的出行应用，流量受天气、地形、节假日的影响比较大。比如拿驾车导航来说，日常大多都是短距离的驾车导航，而国庆、春节大多都是长距离的驾车导航，而长距离的驾车导航对后端算力的要求是非线性增加的，甚至是成倍增加。但长短距离的驾车导航对压测平台来说是同一个接口，而平台目前的精准控压只能做到接口级别，无法模拟接口特征级别的压测。 基于以上两大问题，高德全链路压测团队设立语料智能化专项，重点解决以上相关问题。 解题思路和路径 引流标准化 高德的全链路压测彼时已基本拉通大多业务，但还属于一个演进阶段。对于语料处理，主要由各业务自行处理后用来压测，语料处理的来源缺乏统一性，日志、ODPS、流量等处理来源司空见惯。对于语料生产流程的统一管控，我们首先想到的是统一语料处理来源，必须选择一个低成本、高效率的方式作为语料生产的输入，而流量录制的方式就很切合。经过调研，发现高德其他业务场景对流量录制也有很大的需求。但高德过去的流量录制方式并不统一，各业务线自行拷贝流量经常会引起线上机器不稳定等问题。所以首先要做的是统一高德的流量录制，标准化引流。 语料生产平台化 要统一管控语料的生产流程，上面已经统一了语料生产的输入，接下来就是如何把流量转化为符合平台规范的语料，把整个转化流程平台化。但对于高德业务来说，各个业务都有其自身的特点，如果让平台为每个业务提供定制化的处理逻辑成本巨大，再加上平台对各个业务并不是特别熟悉，也很容易出错。而整个语料处理过程也存在一些通用的处理逻辑，所以我们必须提供一种既支持各业务定制化需求，又可以满足平台通用处理逻辑的方案。我们最终选择通过Flink来完成整个流量处理逻辑。 引流已经标准化，业务方只需查看流量的格式内容，编写Flink的UDF(用户自定义函数)，处理自身业务定制化的需求即可，而后续通用的语料存储等逻辑可通过Flink的sink插件来完成。这样既可以提供通用处理逻辑，又给业务的特殊需求提供了支持，扩展性良好。 语料智能化 上面已经提到高德这种国民级出行应用受各种环境影响比较大，如何达到接口特征级别的精准控压，是当时面临的又一大难题。平台已具备接口级别的精准控压，只需把接口按照特征分类，提供真实流量的特征分布即可。但流量的特征分布是实时变化的，如何提供符合流量高峰的特征分布是语料智能化的最终目标。 要实现语料智能化需要经历3个阶段。第一阶段是流量特征统计。我们需要明确影响流量变化的因素，体现到流量上就是具体的参数分布，具体有哪些参数会随着外界环境的变化而变化。当然这块高德大多业务线都有一些粗略的分析结果，前期可以直接采用，后期就需要有更细粒度的特征分析。 第二阶段是流量特征提取。有了具体的特征参数后，就需要对特征参数进行提取统计，后续可用来做智能预测。但特征参数的提取到底应该如何去做呢？经过综合分析发现放到语料生产的环节最合适。引流拷贝流量，语料生产环节用来处理流量，在这个环节提取特征参数再好不过了。而整个语料生产扩展性良好，对用户的特殊需求通过UDF完成，整个流量特征提取刚好可以在通用逻辑里面完成。 第三阶段就是智能预测与机器学习。有了特征参数的统计数据，就可以借助往年高德地图国庆或春节的流量特征，加上今年随着业务的流量变化趋势，智能预测出符合今年国庆或春节流量特征的数据，做到接口特征级别的精准压测，做到真正意义上的全链路压测，为高德地图服务的稳定性保驾护航。后续也可以借助机器学习自动发现影响流量变化的特征参数，自动采集分析，做到真正意义的语料智能化。 整体方案 整个引流工作将由开发的统一引流平台来完成，引流平台通过引流插件把流量缓存到Kfaka，最终落盘到ODPS。而整个语料生产服务直接对接引流平台，处理来自ODPS的流量即可。 语料生产服务的整体处理过程都由Flink来完成。用户只需编写Flink的UDF来完成自己业务线定制化的需求即可。而且整个Flink的UDF支持多参数传递，用户可灵活编写UDF，在执行过程中动态传递相关参数，解决请求过期等问题。 Flink sink是由平台开发的一个Flink源表解析插件，主要包括流量的特征分析与提取，以及把生产好的语料按照接口命名写入OSS供平台压测使用。目前流量的特征由各业务线自己提供，通过在平台添加完成。Flink sink在执行过程中调用平台开放API获取特征数据进行采集，最终上报给平台，平台后续再根据这些数据进行机器学习，智能预测出符合流量高峰的流量特征，供全链路压测使用。 核心功能介绍 Iflow引流平台 基于上面的问题分析，高德工程效率团队积极迎接挑战，短短几个月开发了Iflow引流平台，对高德的引流进行了统一管控，具体如下图所示： Iflow引流平台以任务的方式对高德的引流进行管理。目前采用引流插件的方式进行流量拷贝(后续将支持更多引流方式)，流量通过Kafka缓存，最终写入ODPS供大家使用。用户只需要从ODPS提取需要的数据即可。而启动引流需要相关负责人审批，周知到关联业务，有效的降低了引流引起事故后排查的成本。 TestPG语料智能化 高德全链路压测平台语料智能化主要由3个模块组成：业务线管理、压测名单管理和接口比例管理。业务线管理主要用来管理高德各个链路的相关数据，包括关联引流任务、启动引流、引流记录、语料路径、压测header管理和触发语料生产等功能。一条业务线就是一条压测链路，从引流到语料生产以及语料特征分析等都是在业务线维度完成的。具体如下图所示： 功能介绍： 关联引流任务：主要完成和引流平台任务的关联以及配置相关的参数。 启动引流任务：启动引流平台任务，在引流结束后会自动触发语料生产，通过执行用户编写的Flink UDF和平台开发的Flink插件，完成语料的生产和特征参数的提取。 语料路径：在每次启动引流触发语料生产后平台会自动生成语料路径，用户可在创建语料的时候自主选择。 压测header管理：每条业务线都有自身的业务特点，在header上的体现也不同，这里主要用来管理压测http服务发送的header内容。 触发语料生产：语料生产有2条途径，一是关联好引流任务启动引流后会自动触发语料生产，包括特征参数提取等一系列的操作；二是在引流成功后，用户可能对UDF等参数有所修改，也可以通过此按钮来触发语料生产。 压测名单管理主要用来管理压测的接口。一个公司开始做压测，业务肯定是需要跟着去适配的，随之而来的就是业务改造，这是一个漫长的过程。为了方便管理，高德全链路压测平台对高德这边的接口进行统一管理。具体如下图所示： 压测名单是在引流过程中自动上报的，引流只要发现未在压测名单的接口就会自动上报压测平台，平台根据关联应用去关联对应的负责人，并推动确认。如果可压测就确认为压测名单，下次语料生产作为白名单正常引流。如果不能压测就区分为免压接口或待跟进接口。待跟进接口平台后续会以消息通知的形式推动业务线改造，最终达到真正意义的接口覆盖全、链路覆盖全的全链路压测。 接口比例管理前期主要是用来管理BI提供的、以及每次全链路压测调整的比较贴近真实情况的接口比例数据，作为后续全链路压测的一个参考。后期将通过语料生产提取流量特征的统计数据，智能分析预测出符合真实情况的流量比例，供全链路压测直接使用，具体如下图所示： 平台优势 语料平台化生产 整个语料生产对接了引流平台，并通过Flink来完成。既支持了业务方定制化的需求，也支持平台通用化的处理逻辑，扩展性良好。通用逻辑通过Flink sink来实现，并加入了流量特征提取等功能，推动了语料智能化的顺利进行。用户只需要学习Flink完成UDF的编写，然后在平台完成相关配置即可。很大程度上提高了语料生产的效率和质量，是语料从格式标准化向生产流程标准化的一大飞跃。 语料智能化 平台在整个语料生产的过程中，通过Flink插件完成了特征参数的统计汇总。目前用户只需在平台完成相关特征的配置，平台在语料生产过程中就会分析特征并统计汇总。有了特征参数的统计数据，将有助于平台后续的智能分析与预测，达到接口特征级别的精准控压，最终达到完全意义的全链路压测。 长按订阅更多精彩▼ 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！