22年个人总结

长话短说版:没人用的产品,价值为0。

下面是絮絮叨叨。

22年之前的5年时间里,主要都投入在我们公司的物联网业务上,21年下半年有几个伙伴成长不错,就把业务交接给他们,让他们来管,我自己从新注入到公司的云通信业务上。表面上负责产品研发(CTO)和供应链管理,实际上主要投入的精力偏后者,前者也有靠谱的小伙伴们在一起做,所以不用操心太多。供应链方面,我们这么多年下来都没有一个非常核心和稳定的leader在负责,所以我跟老大主动请缨,负责了起来,期望能把公司的资源(主要是运营商、云厂商的资源)做的更稳健,把资源的调配和运营做精细化,总体操着降本增效,同时兼顾质量稳定去做。

22年,在技术方面,主要是系统学习了区块链的一些技术原理,包括比特币的共识机制、挖矿原理、加密货币钱包原理,以太坊的智能合约原理。总体上,对区块链的认知上更深入了几层,比之前停留在『炒币』的概念上增加不少知识。当然这种系统的学习,不代表能把这种市场的反应机制看清,所以依然不参与炒币。比如最近的这一波比特币行情就完全错过了。

在开源方面,更多倾向于了解成型的开源产品和开源社区的运作模式,而不是开源框架。了解和学习了开源软件社区的运作模式,主要了解了与我们云通信产品有较大相关性的上下游产品。发现现在开源软件,更多的喜欢用小而美的语言开发,例如NodeJs、Typescript、Ruby、Python、Golang、Rust等等,而老牌的Java、C++、C#等语言比较少被用来开发开源软件产品。开源社区的运营和公司的运营相比并没有更简单或更难之说,都是需要投入大量精力去做才有可能做好的。现在很多开源软件产品也经常喜欢把软件核心开源,吸引开发者,把开发者转化为用户,然后通过提供商业版或者在线SaaS版、托管运行的模式来盈利,这就解决了很多产品的营销问题,不太需要为产品投入太多的市场营销费用。当然,开源产品的营销也是有成本的,找业界大佬带货,把star数做高都是常见套路。经常会有一些成熟的商业软件的开源替代品(Alternative)出来,宣传是某某软件的平替。但其实,大多数开源软件只是解决了功能上的相似,很多大型的商业软件在生态建设上投入非常高,建立的商业壁垒也很高,不是说你开源就容易替代的。开源的另一个好处是解决一些数据上的信任问题,降低开发者的决策壁垒,有一定的好处。如果说一个开源社区运作的好,他的生态就是参与到这个社区的开发者,通过开发者来打通各种上下游软件(包含商业的和开源的),把开源生态一步步建设起来,前期一定是很难的,关键还是得要持之以恒的投入。虽然很多开发者看起来像免费的劳动力,但开发者的质量参差不齐,对需求、问题的响应较慢,这也是开源社区相对于商业软件的劣势,需要时间来沉淀,慢慢的完成逆袭。

在供应链和资源管理上,主要更多的是出于合作互补的方式,把别人的长项引进来,补充我们的弱项,再把我们的长项包装出去,输出给用户。其中资源的运营也是非常核心的部分。对于资源运营,最核心的就是通过灵活的调度手段,把合适的资源匹配给合适的客户。那就需要做到精细化的运营,对客户的需求本身要有比较深刻的把握,对资源本身的特性也要区分好。评判资源的优劣,要有多维度的考量,比如质量、价格以及配套的服务等方面,从中衡量出资源的优劣程度,再结合用户的需求,组合打包,给到客户。

22年给我最大的转变是更多的商业上的思考,以前更多是「技术改变世界」的理想主义,一个产品不管有没有技术含量,能创造价值就是好的产品,否则都是垃圾。在ToB这个行当里,产品好不好真不是产品、技术说了算,而是你的客户愿不愿意买单。一个产品从研发到交付到客户手上以及后续的服务,是有诸多细节的,从研发、到营销、到运营(解决方案契合客户需求)、到售后服务,都是能体现你产品(公司)价值的地方,而其中最关键的还是营销。ToB的采购中,不像C端用户,自己买自己用,决策链非常端,好用且值得就买。B端的采购,从需求的发起方到决策方到采购方以及到后续的使用方,都是不一样,如果盯着一个非关键决策的链路上打,容易吃力不讨好。当然这里不是说产品做成屎也能卖出去,而是至少要匹配客户需求的,产品在2B的决策链(或者打分)上的权重不是最高的,更多还是商务决策(价格、服务、质量、品牌、口碑、关键关系)上的多维度打分。

总结一下:不管做2B还是2C,产品要及格以上,但关键要想好去哪里圈客户,把客户做进来了,产品才能体现价值,没人使用的产品,价值为0,如果再算上研发成本,价值就是负数了。

关于新能源的思考

基本原理: 能量守恒原理  + 能量转换损耗。

1 能量守恒,意味着不论能量怎么转换,能量都是那个量。 Eo = En + El  , Eo 表示原有能量,  En表示新的能量形态, El表示转换过程损耗的能量大小。 非理想状态下, El都是大于0的。

2 能量转换,在非理想状态下,是一定有损耗的,而且在现实中,损耗还挺大。所以目前科学的研究很多专注于如何提高能量的转换效率,比如太阳能转电,风能转电等等。

新能源的形态:

太阳能、风能、水力发电、潮汐能、地热能、生物能、核能,基本上要么是能量来自于大自然,要么能量释放效率巨高。

储能:

由于很多新能源就是自然资源,自然资源与我们传统的化石能源相比有个特点是能量的获取不稳定与不持续,例如风能,有时候风大,有时候没风;太阳能,白天有,晚上没有 等等,意味着这些能源获取到之后,如果直接拿去给电力设备使用会出现不稳定的状态,需要能量存储器,做做存储,在发电高峰期做储能,在发电低峰期释放能力,以稳定整个电力网的状态。

非对称加密算法

前言

目前主流的非对称加密算法主要有几类:RSA、DHKE、Elliptic Curve。

虽然大类分成这几类,实际上他们底层的原理都是依赖于素数和同余原理来做的。素数是除了他本身和1以外,无法被其他任何正整数整除的数字。这样的数字有多少呢?无穷个。我们知道,一个数字的因式分解,最终都能分解成n个素数的相乘,由于素数有无穷多个,也就意味着一些巨大的数是很难分解的,特别是两个大的素数(例如几百位、上千位)的乘积就更难因式分解了,催生了很多在理论上不可行,但在经济上可行的加解密算法。为什么说是理论上不可行呢?因为数字再大,只要有恒心(例如几百年、上千年甚至几百亿年)总能把一个大数因式分解,也就是基本假设不成立,一旦能因式分解,所有的这类密码都将被破解。经济上可行是因为,因式分解一个这样的大数字花费的经济成本(计算机、电力等)太高,以至于不会有人去尝试暴力破解。当然,据说有可以破解这类的量子算法,基于量子计算机多维度并发计算,还是有机会的。目前量子计算机造价昂贵且还没有大规模商用,用于破解这类的密码成本也是相当高的,暂时还是安全的。对应的策略是,a:发明后量子加密算法,在量子计算机流行之后也能用后量子算法来加解密,保障量子计算机破解不了这类的密码;b:用量子纠缠实现通信,可以完全杜绝中间人攻击,此时密钥不是最重要的了。目前美国为主的西方国家主要在主导后量子密码学,而我国科学家更多在主导量子通信。

下面我会用相对易懂的预言推导一下这几类算法的原理,一些不太好理解的定理,不会太深入去推导。

基于区块链的端到端加密通信

基于区块链的端到端加密通信

端到端加密通讯的基本原理

端到端基本上都是基于非对称加密手段来实现:假设通讯双方为A和B,AB都 自己生成一个随机的 私钥(p) 并私密地保存起来,然后通过数学算法,生成一个 公钥 (L),把公钥发送给想要跟自己通讯的点(peer)。当他们要给对方发送信息的时候,将信息用对方给的公钥进行加密,然后通过网络发送到对方;此时对方可以用已保存的私钥,解密加密后的数据,得到信息原文,实现了信息在传递过程的私密性。用描述语言如下:

A gen  pA/LA, store pA, send LA to B
B gen  pB/LB, store pB, send LB to A

发送消息时:
A.sendTo(encrypt(message, LB), B),发送的是用B的公钥加密过的信息。
B给A发送的状况类似。

接收消息时:
B.receiveFrom(A).decrypt(pB),接收到A发过来的加密信息后,用B的私钥解密,得到信息原文。
A 接收到加密信息之后的处理方式类似。

有中心化服务器的加密通信

去中心化的身份标识(DID)

去中心化的身份标识(DID)

前几日(2022年7月19日),w3c发布了去中心化身份标识(DID)1.0版的标准,意味着这个标准已经成熟可落地。

DID全称叫去中心化的身份标识,可以认为是类似于区块链网络帐户地址或者能唯一确定一个用户的身份(例如每一笔比特币的交易记录都可以确认到发起人的帐户公钥,也就能知道地址)。核心还是基于密码学上的非对称加解密算法,生成一对私钥和公钥的密码对,身份持有者私密的持有密钥,而需要用于身份标识验证的时候,验证方可以拿到公钥进行验证。 在之前的区块链钱包文章我们说过,椭圆曲线算法基于非对称的加密方式,提供两个方向的用途:1)公钥加密私钥解密,适用于加密通信;2)私钥签名公钥认证,适用于数据验证。理论上非对称加密的身份认证不基于区块链网络或者分布式账本技术(DLT)也能运转,但区块链或者分布式账本的存在,让DID才真正实现去中心化的可广泛使用的用途,下面我们来说说不用区块链(分布式账本)的情况下,DID存在什么问题、区块链是解决这个问题的。

公钥分发难题

区块链钱包

区块链钱包

直观概念
区块链钱包,存储的仅仅是区块链帐户的私钥,其他相关概念都是通过私钥衍生出来的:比如帐户地址、帐户余额等等,并不是说有钱存储在钱包里面。

钱包的分类
钱包从管理权上分为托管式的和非托管式的。托管式的钱包:比如你在区块链交易所,交易所会自动给你生成一个软钱包,这样别人才能把资产转移到你的帐户里,但你的钱包的密钥都放在交易所上面加密保存,存在一定风险。非托管式的钱包:你自己管理私钥,通过软件、硬件等方式管理你自己的私钥,在需要转移账户上的资产时,用私钥做签名运算即可。

钱包从电子技术方面分为软件钱包和硬件钱包。 软件钱包一般是通过钱包APP来帮助生成私钥(通常会有助记词),然后在线上用区块链资产消费时,可以直接这些钱包APP进行支付,收款等方式。这类的钱包App特别多,基本上都声称数据存在本地,但安全性方面不好说。硬件钱包一般是通过一些安全硬件来实现,在需要签名使用时,通过USB等方式连接到电脑或手机,硬件层面直接做签名,不往外泄露任何私钥信息,安全性较高一些。

钱包从存储介质方面分为冷钱包和热钱包。冷钱包是通过物理的方式,把钱包的私钥信息(或者助记词)记录到物理介质上:比如手写笔记本,拓印的钢板等等(注意这些都要安全保存起来),主要用于备份私钥,防止软硬件钱包丢失后,帐户找不回的麻烦(区块链钱包因为是去中心化的,没有一个中心方负责管理,一旦丢失了密钥,整个帐户也就意味着丢失了,再也找不回来)。热钱包就是泛指前述的几种电子化的钱包,使用比较频繁。

非对称加密算法

关于比特币区块链网络

关于比特币区块链网络

题外话

关于比特币,或者区块链,我了解是比较晚的,第一次接触到区块链这三个字是在11年左右,当时还在阿里上班,当时去听了一个facebook的「区块链」分享,后来了解下来,他们当时说的区块链并不是一个分布式账本,而是一个PC广告相关的业务,也不知道当时是刚好撞名了还是故意蹭的,反正当时了解下来不是很感冒。后来15-16年左右慢慢了解到一些相关概念,大致是了解区块链的分布式账本性质,并没有太多去深入研究。后来公司招了一些人,手上有一些币,一直在跟我们安利区块链的共识机制,我当时也是太年轻,感觉这玩意就是炒做而已,嗤之以鼻。直到近2年才比较系统的去了解这个东西。手上没有比特币,本文也不是为了鼓吹炒币,而是把自己理解的比特币区块链的一些东西分享处理,做个总结(肯定很多理解还是错的,可以评论交流)。

1. 关于区块链的安全性保证

关于SaaS软件与国产化替代的一些想法

关于SaaS软件与国产化替代的一些想法

题外话

转眼间,创业已经10年了,所以一直以来从公司层面看我的工作履历是非常简单的,上一家是阿里巴巴的淘宝网,现在这家就是创业公司,已经长达10年之久。公司虽然没有大富大贵,但目前还没倒闭,还是能持续的为社会创造价值(至少在纳税,至少能解决一些就业问题),也就足够了。最近刚把博客空间名从「jiacheo杂谈」改为「jtalk」,其实没啥区别,我还是我,因为近几年在做一些帮助企业出海的服务的业务,所以就改成一个更容易识别的名称(更洋气?),也算是一个新的阶段的开始吧。

———

关于SaaS软件,我们公司从创业伊始,就是做SaaS软件起家的。当时我们几个合伙人刚从阿里巴巴出来创业,对阿里本身的商品体系有一定了解,也对阿里巴巴的使命「让天下没有难做的生意」这个使命坚信不疑,所以创业的产品还是围绕着电商(2B),帮助商家解决一些问题。因为当时阿里巴巴也在做开放平台(当时主要是基于淘宝网),所以我们就基于淘宝开放平台开放的接口,做了一套SaaS CRM,帮助商家解决和消费者的通信触达问题。

我的2017书单

前言

今年比以往不同的是,看了比较多的书,当然都是浅看,不是工具书我一般都不来回看,看完一遍就在脑子里过一下,也不强求能学到什么知识,只要能从在学到一些新的体会就达到看书的目的了。没错,看书还是要带着目的看的。

大多数书都是用微信读书看的,纸质的也有,但比较少,因为手机在任何地方任何地点都能看,压榨空隙时间第一选择。微信读书的体验还是很不错的,功能简单,而且可以通过读书时长获取读书币,然后读书币可以买更多的书,良性循环。

接下来介绍下每本我看过的书和一些心得体会吧。

我的2017书单

NO1. 《刻意练习》 ⭐️⭐️⭐️⭐️⭐️
这本书是讲一些高效的学习方法的,就是想要高效的学习并深入,除了努力之外,我们还需要带着明确的目标,配套合适的方法,才能做到短时间内领悟更多。 这本书还有一个观点是,天才并不存在的,很多我们看到的天才,只不过是他们在很小的时候,通过《刻意练习》的方法,让自己在某一领域深入掌握各种技巧而已。当然,刻意练习并不简单,需要考验你的耐心,方法以及能指导你的老师(高人)。3F法则(Focus、Feedback、Fix)已成为我的座右铭:)。总之,这本书比《一万小时理论》更值得一看

NO2. 《腾讯传》 ⭐️⭐️⭐️⭐️
这本书就是讲腾讯的发家史,当然写的看似波澜不惊,但是每一段波澜不惊的创业背后都是创业者苦逼的持久战。创始人对公司文化的影响极其深远,创业除了碰运气,还要在浪潮来之前准备好姿势(这需要比常人多十倍、百倍的努力),踏浪而上,成为弄潮儿。另外一点是创业者需要不断的居安思危,不能看到眼前有收入可以养活团队就能『躺着赚钱』了,灾难来临的时候从来不会告诉你,你跟其他公司的区别就是能不能顺利度过去。

NO3. 《资本的逻辑》 ⭐️⭐️⭐️
这本书不建议看电子版,因为电子版制作很粗糙,很多数据图表都没有了,而且小数点也没有,所以会经常看到一些奇怪的巨额数字,需要自己去脑补实际的金额。最重要的一句话:企业的估值是向前看,而不是向后看。 估值就是对未来的期望值。

NO4. 《未来简史》 ⭐️⭐️⭐️⭐️⭐️
这本书可以和《奇点临近》一起看,预测在不远的未来,随着超级人工智能降世,人来的价值观会发生什么样的变化。从科学的角度讲,人类本身没什么意义,都是一堆算法和随机过程的组合而已,人类的这几百万年的进化,极有可能是为了唤醒地球上的超级人工智能生命体而已(远古的天外文明埋下的种子,哈哈)。未来,如果人类和超级人工智能结合之后,不再死亡,也不再有肉体,那么我们现在的宗教里面天堂、地狱、神都不再有意义,那么,这些有神论者,该如何自处?

NO5. 《即将到来的场景时代》 ⭐️⭐️⭐️⭐️
传感器 + 物联网 组成的雾计算,以及以云计算为基础的ai技术,通过整合人类的各种数据,做到书中描述的场景时代并不难,难的是道德上的变革:隐私数据该不该共享?数据的所有权、隐私问题、网络安全问题,这几大问题没有好好的解决,还是很难铺开。当然,可以接受的是,新技术的变革和流行,反过来推动这些问题的解决(或者更大的利益来抵消损失的权益)

NO6. 《人民的名义》 ⭐️⭐️⭐️⭐️
这个不多说,一切为了剧透。 这本书(或者这部剧)名义上是以『人民的名义』写反腐,实际上是以反腐的名义写当代中国官场现形记。 主角和他的盆友们都是官二代、红二代,很容易形成抱团取暖、勾心斗角。

NO7. 《奇点临近》 ⭐️⭐️⭐️⭐️⭐️
技术正在加速进化,我们处在变化中,如果看的时间不够长,会以为是比较常规的线性变化,而把时间轴拉长,会发现我们正处于技术变革的指数曲线上。我们正在走向变革的奇点。如果不抓住机会乘势而上,那我们之于即将到来的超级人工智能就像尼安特人至于现代智人一样,将会被灭族!不过作者对强人工智能总体上是比较乐观的,认为生物智能(比如人类)和非生物智能可以完美结合,和谐相处,合体之后变成全新的超人类(感觉在看龙珠Z)。技术的进步总会带来一些毁灭,但阻止技术进步并不能阻止毁灭的降临,所以我们应该更加加大力度发展技术,让毁灭来临之前,我们人类的技术可以与之抗衡。

计算机终将拥有意识,到时候人类不小心把一个计算机关机了并摧毁了,会不会犯了杀计算机(or机器人)罪?

作者的一些预测观点已经发生或者正在发生,再过20年,人类之上,会不会有新的物种出现?拭目以待吧。

NO8. 《增长黑客》 ⭐️⭐️⭐️⭐️
这本书内容还可以,就是文法比较散漫,语法比较随意,对于刚接触互联网的新人(尤其是上了年纪的),不会容易理解。增长黑客的主要工作就是用各种『黑客手段』(超出常人一般的做法,不是指真的黑客)驱动公司的业务增长。主要从运营的角度,从获客、到转化、活跃、留存、老带新等阶段,做与之相匹配的操作,驱动各个阶段的增长。

NO9. 《格鲁夫给经理人的第一课》 ⭐️⭐️⭐️⭐️⭐️
这本书字字珠玑,对刚接触管理工作的人,会很有帮助。不多说了,自己看吧。

NO10. 《你一定爱读的极简欧洲史》 ⭐️⭐️⭐️⭐️
今年流行各种《极简xx》,这本书对于历史经常考试不及格的我还是很有启发,简洁明了。总结起来,整个欧洲的历史和罗马文明分不开,虽然罗马早就亡国了,但他的影响,一直留存到现在,这就是文明的力量。

NO11. 《周鸿祎自述:我的互联网方法论》⭐️⭐️⭐️⭐️
这本书主要讲解周鸿祎的互联网思维,每个互联网大佬都有自己互联网思维。雷军的互联网思维就是用效率升级改造产业链,产出物美价廉的高性价比产品打击存量市场,把用户留住,然后在用后续的其他手段获利。周鸿祎也差不多,只不过在软件层,而不是硬件层这么做。互联网思维的核心点除了免费(或高性价比)之外,其实是要做到以用户为中心,以产品价值为核心,才能最终留住客户,你才能做后面的事情。

NO12. 《自私的基因》 ⭐️⭐️⭐️⭐️⭐️
这本书看书名容易产生误解,以为基因本身有思考能力,否则他怎么做到『自私』?其实不然,基因就是一种复制子,他的使命是更长久的(复制自己并)存活下去。基因的自私不代表人性的自私。基因创造我们的身体和大脑,但他并不能直接控制我们,而是通过代码片段,对我们造成影响。人类的文明史就是基因和幂母(MEME)的斗争史。幂母也是一种基因,他也是一种复制子,也有『自私』的特性。以后产生的超级人工智能,可能就是幂母的一个后代而已。 机器人要变成『人』,一定要突破如何繁衍下一代的关卡,比如纳米机器人很可能就是下一代地球的霸主。

NO13. 《极简宇宙史》 ⭐️⭐️⭐️⭐️
非常Exciting的一本书,一场非常有趣的思想实验。从万有引力到相对论到量子力学再到弦理论,每种很牛逼的理论都有他们的适用范围,接下来科学家都在搞的就是一个大而统一的理论,可以把这些所有的理论都兼并起来,解决他们之间的冲突。这一切只是时间的问题,而这个时间,对浩瀚的宇宙来说,不过是一瞬间的事。

NO14. 《大国大城:当代中国的统一、发展与平衡》 ⭐️⭐️⭐️⭐️
看完这部书,我为中国感到前途光明。因为我们的城市化是这么的畸形,而这些畸形都是内部的问题造成的,不是别人束缚我们,所以我们只要愿意改革,再上进几个层次都不是问题。从大局的眼光看,当前的既得利益,都一文不值。其实我们生活在城市里,有城市户口,对大多数农民工工来说,我们都是既得利益者。最近北京搞的一些脑残的清理xxx的运动,简直就是逆城市化行为,历史的车轮的滚滚向前的,这些拍脑袋的人阻止不了我们伟大的时代到来。

2017总结

看的书比较杂,这里技术类的不列出来,技术类的书我建议还是看纸质的,图文并茂更容易理解。关键要带着目的去看,然后看的同时一定要多动手,举一反三,才能更快掌握技术类的新知识。 当然不是所有书都要带着功利的目的去看的,比如《人民的名义》这种就是为了娱乐放松下。

读书容易给人一个感觉,就是读的书越多,会越觉得自己无知。但没必要觉得气馁,你get到了,你就比别人进步了。

2018书单

  1. 《长尾理论》
    这本书刚开始看,没看完,2018年看完。

  2. 《小米生态链战地笔记》
    这本书看了几章,都比较接地气,同时我目前也正在做物联网相关的工作,然而小米在4年前就开始布局了,然后现在去他们的米家商城看,哇塞,除了手机,其他都做的很不错,特别他们的只能家居这块,米家app里面居然可以编程,不得不佩服雷军的眼光。

  3. 《创新者的xx三步曲》
    周鸿祎教主推荐的,在他的方法论那本书里,今年买的还没看多少,2018看完。

  4. 《TensorFlow 系列》
    了解下当前ai都在干啥,希望在超级人工智能这个新物种降临之前,能知道他们是怎么生存的。

Java性能问题排查经验分享

前言

好久没动笔写博客了,为了不给2017留空白,特写此篇。 这篇文章提到的案例、方法、方案有些是在之前的文章中会零散提到过,都是在公司内部分享多次以及迭代多次的结果,当然,敏感数据的地方我会换成一些fake的数据,注重方法论,数据上有问题的地方请包容。

这个话题其实可以涉及到各种各样的场景,我这里仅仅是把我们公司内部经常遇到的一些问题拉出来分享。本文的案例基本上都基于linux环境的java程序进行分析,如果你是windows或者其他的操作系统,可能有些工具需要自己寻找、下载。

首先讲讲排查思路

1. 出现问题之前,是否刚刚做了发布(上线新的代码:功能、修改等)

  • 是:结合内部的服务器监控系统(zabbix等)的数据,判断是否在发布的时间节点前后发生不一样的现象,如果是,基本可以断定是新代码导致的问题,第一时间回滚代码(如果可以的话,技术方案设计上本来也要考虑失败回滚的问题),先恢复应用的正常访问(服务),再分析新上的代码是否有问题。
  • 否:如果是历史遗留的问题,就需要结合工具来排查(这写就是本文会讲解的重点)

2. 关于日志

  • 日志不是越详细越好,记录关键信息才是真理。如果每次打印日志都把过程数据写上,反而容易引起磁盘io问题、内存频繁ygc问题。
  • 日志要有意义,debug性质的日志一律用 debug级别,线上禁止打印 debug级别的日志。
  • 区分性能日志和业务日志:性能日志用于发现性能问题,业务日志用于记录业务流水方便后期追溯。

排查工具

  1. ps | grep 组合命令, 方便快速找到进程id(java有自带的jps工具)
  2. vi/tail/head/more/less: 查看线上日志的工具,注意不要用vim打开打日志,往往会给(内存)负担过重的服务器致命一击
  3. awk 文本分析脚本,可以快速分析性能、业务日志,得出结果,不用等大数据平台一系列流程
  4. top:查看进程(和线程)的cpu耗时,内存占用情况
  5. iotop:查看进程和线程的IO消耗情况 (需要自行安装)
  6. iftop:查看进程和线程的网络情况 (需要自行安装)
  7. lsof:查看文件打开情况(含网络、本地文件、设备等)
  8. JVM系列tools (本文重点)
    • 8.1 jstat:查看进程内存分配和gc情况
    • 8.2 jstack:查看进程的线程栈
    • 8.3 jmap:dump java 内存。(不要对在线提供服务的应用做jmap)
    • 8.4 btrace:运行中的代码调试
    • 8.5 jprofile: 外挂的形式,分析具体到方法级别的相应耗时,压测配合jprofile,能直接找到瓶颈
  9. IBM Memory Analyzer Tool, 简称MAT,用于分析 jmap 命令dump出来的内存文件
  10. 监控工具
    • 10.1 zabbix:观察系统的历史性能状态(顺便告警)
    • 10.2 ganglia:观察系统的历史性能状态
    • 10.3 vision: 我司内部自研系统,观察业务的性能数据,QPS vs RT
    • 10.4 各式APM工具,比如OneAPM,听云等,通过javaagent的方式实时分析程序的性能问题

一些案例

案例1. 进程耗CPU咋办

一般两种问题:
– a. 业务代码中有大(或死)循环,消耗大量CPU计算资源
– b. 垃圾回收(GC)频繁,导致gc线程消耗大量CPU (FullGC、YoungGC均会消耗CPU资源)

针对a情况,如何找到消耗CPU的代码段?

  • ps | grep 组合键找到进程id
  • top -H -p $pid 列出线程详情 (-H命令可以显示线程情况)
  • 找到耗CPU最高的几个线程ID ( 同时按下 shift + T , 按CPU时间(Time)排序) ,在-H模式下,pid就是线程id
  • printf %x $tid 把线程ID转化为16进制, 记录下来
  • jstack -l $pid ,dump出线程栈 ,最好写到文件里
  • 通过第四步得到的线程ID的16进制,在线程栈里面找到相应的线程栈信息 (nid=0x16进制线程ID)

至此,定位到的代码段一般就是耗CPU的代码段了。

通过上述排查,如果耗CPU的线程是VM Thread,说明是进入了b情况

  • 首先,我们必须清楚gc的情况,如果没有开启gc日志,只能通过 jstat命令查看
  • jstat -gc $pid , 观察 YoungGCCount 和 FullGCCount 的增速
  • 如果ygc快速增加,说明是新生代内存分配和回收过快 (比如每秒增加几十次ygc),此时需要结合观察日志,看某种业务(服务)是否在快速打日志,是的话一般就是此处的频繁工作引起问题。
  • 如果fgc快速增加,说明是老生代的内存一直不够用(晋升失败),此时可以通过jmap 命令dump内存,到本地用mat工具分析

案例2. 进程or线程hang住了怎么办

一般原因

  • 死锁(本地锁&分布式锁)
  • 依赖的远程服务hang住&没有设置超时时间
  • 线程池耗尽 or 连接池耗尽
  • 死循环
  • 调用网络服务,但网卡带宽被耗尽

解决方法

  1. 排查是否死锁
  2. 设置远程服务(含API、MQ消息、分布式锁等)的超时时间,业务需要兼容
  3. 调高线程池or连接池 & 缩短超时时间(业务需要做兼容)

排查死锁的方法

很简单,通过jstack工具,他会直接告诉你死锁在哪。
1. 找出进程ID
2. jstack -l dump出线程栈
3. 通过 deadlock 关键字找到相关线程信息即可

案例3. 进程周期性卡顿怎么办

一般原因

  • 有定时任务,定时任务触发时把系统拖慢
  • 有定时fullgc,可能是定时任务导致的fullgc,也可能是定时触发fullgc。fullgc时会stop the world。

解决方法

  • 如果是定时任务,优化定时任务对内存的使用
  • 如果是定时触发fullgc,而系统不能接受,则配置vm参数禁用fullgc

排查过程

  1. 启动参数中要添加gc日志
  2. 如果没有gc日志,则通过jstat -gc 命令来查看gc情况
  3. 如果OU(old区使用量)远远没有达到OC(old区容量)就触发了fullgc,一般是定时触发,可以通过添加 -XX:+DisableExplicitGC 参数禁用定时触发的fullgc。

案例4. 进程OOM怎么办

首先,要先知道有哪些OOM,每种OOM都是有什么问题引起的。

OOM种类

  • gc overhead limit exceeded :jvm花大量时间回收少量的内存。
  • java heap space:heap内存不够用,无法继续分配内存,且无法回收足够的内存
    • heap的大小由 -Xms 和 -Xmx 决定
    • 一般配置了 -XX:-UseGCOverheadLimit 就不会出现gc overhead limit exceeded 问题, 最终会变成 java heap space
  • unable to create new native thread:超过资源限制
    • 进程、线程数超过了系统限制(ulimit)
    • 线程数超过了kernel.pid_max的限制
  • perm gen space: 持久代不够用
    • 持久代不够用,调大 PermSize 参数
    • 调大也没用?怀疑classloader错误使用。
  • direct buffer memory :堆外内存使用超出限制的大小
    • 如果机器内存足够大,可以调大 -XX:MaxDirectMemorySize 参数
    • 一般是网络通信没有限流,而且用内存做buffer
    • 定时fgc 主动回收堆外内存
  • map failed: FileChannel map的文件超过了限制
    • 调大 vm.max_map_count 系统参数可解
  • Requested array size exceeds VM limit: 创建数组大小超过jvm限制
    • 创建Integer.MAX_VALUE – n 以上长度的数组会抛出, n和jvm实现、系统环境有关
  • request ? bytes form ?. Out of swap space
    • 地址空间不够用(一般32bit系统才会碰到),物理内存耗光
    • 强制触发fullgc看有没有好转,有的话可能是DirectByteBuffer误用造成的
    • jmap -histo:live $pid 可以强制触发fullgc。

排查过程

  1. 先把服务摘离线上服务集群
  2. dump服务的内存,由于OOM后java进场可能会无法直接访问,需要使用jmap的-F参数强制dump
  3. 将dump出来的文件拉到本地环境,用mat工具分析。

参考链接

  1. 阿里研究员 毕玄 的博客:http://bluedavy.me/
  2. 官方troubleshooting文档:http://dwz.cn/javatsg
  3. OOM shooting: https://plumbr.io/outofmemoryerror