- 博客(153)
- 资源 (1)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 字符集编码
为了解决这种“一锅粥”式的混乱局面，1992年，Unicode出现了。这个128个字符用来表示大小写字母、数字0～9、标点符号、以及像“#”、“@”、“）”、“\r”（回车）、“\n”换行、“\t”（制表）等这样的特殊符号，如图1-12所示。发出的内容是什么，收到的内容就是什么，也不会出现类似“?由于计算机只能存储和处理二进制的“0”和“1”，无法处理其他的字母、数字和符号，所以就需要有某种东西来达到类似桥梁的作用——例如图1-7中的ASCII——通过它，人们就可以看懂用计算机表示字母、数字或其他符号。
2024-12-11 18:53:54
268
原创 二进制文件
并不是，因为在右边部分的剩余内容中可以看到其他和这个文件相关的一些信息，如创建文件的软件工具，文件创建时间等信息，这和用Windows属性工具显示出来的信息是一致的，如图1-10所示。我们在计算机中看到的各种文件，例如文本、图片、音乐、视频、Word文件等，对于计算机来说，没有任何差别，因为它们都是由“0”和“1”组成的。上图中间部分第一行第二至四列的内容分别为“01010000”、“01001110”和“01000111”，按照图1-7中的方法，它们分别对应ASCII中的“P”、“N”、“G”。
2024-12-09 22:03:49
958
原创 统治地球的冯·诺依曼们
虽然关于谁才是真正的“计算机之父”至今没有确切的定论，有人认为是查尔斯·巴贝奇（通用计算机之父），有人认为是阿兰·图灵（Alan Turing，计算机科学之父），有人认为是约翰·阿坦那索夫（John Vincent Atanasoff，电子计算机之父），还有人认为是冯·诺依曼（现代计算机之父）。只是由于他的设计“过于先进”，那时候的世界还制造不出他所需要的设备。尤其是目前业界如火如荼的大模型训练，以其千亿级别的超大规模参数、庞大的数据与算力需求、模型的精细化调整、能源与效率的优化等，让人们想要爱它不容易。
2024-12-08 17:45:01
599
原创 程序员的数学之余数II
按照之前求余数的那种规律，该怎么求的最后一个数呢？的结果是`1`，个位数是`1`的结果是`123456789`，的个位数是`9`的结果是`15241578750190521`，的个位数是`1`的结果是`1881676371789154860897069`，的个位数是`9`的结果是`232305722798259244150093798251441`，的个位数是`1`的结果是`28679718602997181072337614380936720482949`，的个位数是`9`
2024-11-27 23:28:52
338
原创 程序员的数学之余数
294天后是周一` -> `295天后是周二` -> `296天后是周三` -> `297天后是周四` -> `298天后是周五` -> `299天后是周六` -> `300天后是周日`其实这种方法还可以扩展到一切使用进制来计数的地方，例如，现在是早上`08:00`，10的100次方个小时后是几点呢？`奇数`本质上就是被2除余1的数，而`偶数`是可以被2整除的数。如果今天是周一，那么7天后、14天后、21天后、......294天后，仍然是周一，所以，结论是下面这样的。为什么是每6个而不是7个？
2024-11-19 21:46:37
160
原创 程序员的数学之归纳法
这就是数列计算公式`(1 + n) × n / 2`的由来——现在终于知道为什么要除以`2`了，因为就是只计算一半的面积。求`1 + 2 + 3 + ...... + 99 + 100`的值，就变成了计算黄色部分方块的面积了，真是太巧妙了。`100`、`200`，甚至`300`以内还能勉强这样做，但如果要从`1`加到`1亿`，就不可能继续用这种土办法了。因为单个`1 + 2 + 3 + ...... + 99 + 100`可以用数字阶梯来表示，就像下面这样。而两个数字阶梯，就可以`组合`成一个`长方形`。
2024-11-16 20:53:56
285
原创 程序员的数学之进制与零
最近一年多发生了很多平凡的大事，应接不暇，一度断更。从今儿起再接上来。先从数学开始吧，因为太枯燥了。生活中有许多种进制在共同起作用，例如，数学上的`十进制`、计算机中的`二进制`、`八进制`和`十六进制`、计时的`60进制`、`24进制`和`7进制`。怎么才能快速地知道`1111`所对应的具体的进制数值呢？例如，`1111`对应的`二进制`、`八进制`和`十六进制`是多少？它对应的`60进制`、`24进制`和`7进制`又分别是多少？
2024-11-14 22:03:14
667
原创 JVM系统优化实践（23）：GC生产环境案例（六）
在互联网大厂中，对每天亿级流量的日志进行清洗、整理是非常常见的工作。在某个系统中，需要对用户的访问日志做脱敏处理，也就是清洗掉姓名、身份证号、手机号等个人隐私信息后在保存到数据库中或者交付给其他应用使用。
2023-07-26 19:55:37
503
原创 JVM系统优化实践（22）：GC生产环境案例（五）
除了Tomcat、Jetty，另一个常见的可能出现OOM的地方就是微服务架构下的一次RPC调用过程中。笔者曾经经历过的一次OOM就是基于Thrift框架封装出来的一个RPC框架导致的宕机。
2023-07-24 20:02:44
879
1
原创 JVM系统优化实践（21）：GC生产环境案例（四）
前面说了一般应用的OOM情况，但是OOM不知发生在应用层，有时候专门负责运行Java的Tomcat也会偶尔罢工一下，抛出OOM异常。因为Tomcat本身也是一个JVM进程。
2023-07-21 19:45:26
357
原创 JVM系统优化实践（20）：GC生产环境案例（三）
某新手开发工程师接到了一个保存Elasticsearch日志的任务，以供后续分析之用。但写代码的时候，误将保存日志的代码段弄成了无限循环，程序启动后，没用多久就崩溃了。
2023-07-19 21:08:57
1358
原创 JVM系统优化实践（19）：GC生产环境案例（二）
接昨天的问题继续来说，在高并发场景中，对象过多容易导致OOM。由于高并发导致Young GC存活对象过多，因此会有太多对象进入老年代，导致老年代也被填满，频繁触发Full GC，而老年代空间也很快被塞满。可以用图来表示。
2023-07-17 20:25:03
436
原创 JVM系统优化实践（18）：GC生产环境案例（一）
生产环境中，最常见的一种案例就是OOM，也叫「内存溢出」，它表示JVM已经无法支撑业务系统的运行。而很多工程师都没有类似处理线上系统故障的经验，尤其是这种突发的故障。
2023-07-15 07:30:00
359
原创 JVM系统优化实践（17）：线上GC案例（二）
GC的概念并不难明白，而且它的原理也不复杂，但是很难用好。6、老年代Full GC触发规则:老年代已用空间大于老年代空间阈值、Young GC前：老年代可用空间小于历次Young GC后进入老年代的对象的平均大小、Young GC后：老年代空间放不下Young GC后存活对象；用jstat观察JVM的运行过程，尤其要注意：Eden区的增长速率、Young GC频率、Young GC耗时、Young GC后多少对象存活、老年代增长速率、Full GC频率、Full GC耗时。欢迎骚扰，不胜荣幸～
2023-04-19 07:30:00
561
原创 JVM系统优化实践（16）：线上GC案例（一）
一般新手工程师在部署生产环境时基本不会对JVM进行设置，基本跟上也都是使用JVM的默认设置，这是一个很大的隐患。例如，如果不设置-Xmx或者-Xms的话，可能初始的年轻代和老年代就几百M大小。Full GC一般在正常情况下，都是按天为单位来发生的，比如每天一次，或几天一次Full GC。
2023-04-18 07:30:00
403
原创 JVM系统优化实践（15）：GC可视化工具实践
线上系统的JVM监测要么使用jstat、jmap、jhat等工具查看JVM状态，或者使用监控系统，如Zabbix、Prometheus、Open-FaIcon、Ganglia等。作为一个工具人，怎么能不懂jstat、jmap、jhat呢？
2023-04-10 07:30:00
496
原创 JVM系统优化实践（14）：GC可视化工具
工欲善其事，必先利其器。知道了GC工作原理，学会了看GC日志之后，再来了解一下分析GC的工具。它们分别是jstat、jmap、jhat。
2023-04-07 07:30:00
392
原创 JVM系统优化实践（13）：GC动手实践
上一次留了个小尾巴：怎么以通过代码模拟对象年龄在15岁之后才进入老年代呢？自己试着实现了一下。然后再结合之前了解的其他GC知识，来模拟更多的触发GC的实例。
2023-04-03 07:30:00
251
原创 JVM系统优化实践（12）：GC日志分析
了解了基本的G1垃圾回收机制以后，就可以结合实际日志分析一下它的日志内容了，以后再遇到问题自己也能看懂。
2023-03-27 21:38:29
651
原创 JVM系统优化实践（11）：GC如何搞垮线上系统
看了那么多G1 GC的传说，再来看看一些具体的GC案例以及怎么预防GC把工程师精心设计的系统给搞垮。
2023-03-23 07:30:00
417
原创 JVM系统优化实践（10）：G1混合回收
G1替代了ParNew+CMS这对搭档组合，既能实现年轻代的垃圾回收，也能实现老年代的垃圾回收。现在继续来说说它的混合回收问题。
2023-03-21 07:30:00
442
原创 JVM系统优化实践（9）：G1垃圾回收器
在JDK8及其之前，一直用的都是ParNew+CMS的组合：ParNew负责年轻代的垃圾回收，而由CMS负责老年代的垃圾回收，但会产生Stop the World这个无法避免的问题。
2023-03-08 07:48:19
599
原创 JVM系统优化实践（8）：订单系统的垃圾回收案例
上回说到了年轻代和老年代的两个垃圾回收器：ParNew和CMS，并且将CMS的GC过程也一并介绍了，现在来看个订单系统的案例。
2023-03-06 06:58:11
439
原创 JVM系统优化实践（7）：垃圾回收器与垃圾回收算法
上回说到了年轻代、老年代与数据计算的一个案例。接下来就先讲一讲年轻代和老年代的两个垃圾回收器：ParNew和CMS。
2023-03-04 07:30:00
453
原创 JVM系统优化实践（6）：年轻代、老年代与数据计算
如果当前Survivor区中年龄相同的一批对象总大小 ≥ Survivor总数× 50%，那么这批对象及比它们年龄更大的对象，就都直接进入老年代。但是也有可能在Minor GC之后，发现剩余的存活对象太多，导致其大小总和超过Survivor区域，那么就会把这些对象直接转移到老年代，也不计算所谓的50%。
2023-03-02 07:30:00
342
原创 JVM系统优化实践（5）：什么时候GC以及有哪些GC
既然程序运行会产生大量的废弃物，也就是「垃圾」，那总不能一直堆着不管吧。现在就来粗浅地谈谈Java里面什么时候会触发GC以及有哪些GC。
2023-02-28 07:30:00
743
原创 架构师怎么做管理：接口文档管理
任何一个优秀的互联网系统，都离不开各类研发岗位上工程师们的通力协作，而且这种协作必须是以高效的、低成本的沟通方式进行。软件开发从过去的小作坊到现在几十几百人，到现在成千上万人的同时参与，这里面如果没有一个好的协作工具，是不可能进行下去的。对于工程师来说，开发文档就是这样一个低成本、高效率的沟通工具。但奇怪的是，很多工程师都不愿意写文档，尤其是开发文档（或者说接口文档），因为他们觉得只要有技术就可以了，文档啥的有没有都无所谓。
2023-02-27 18:00:00
429
原创 基于SpringCloud的可靠消息最终一致性06：轮询事务消息
对于同一个事务消息，在正常情况下它要被发送至少两次。这是因为在发送消息之前，TransactionMessageService就已经把消息保存到了数据库中。而在首次消费完消息后，TransactionMessageListener并没有从数据库中删掉，数据库中保存的消息，将被轮询服务AppListenerScheduleExecutor再次发送。
2023-02-27 17:00:00
377
原创 基于SpringCloud的可靠消息最终一致性05：保存并发送事务消息
在有了分布式事务的解决方案、项目的需求、骨架代码和基础代码，做好了所有的准备工作之后，接下来就可以继续深入了解「核心业务」了。
2023-02-27 16:00:00
385
原创 基于SpringCloud的可靠消息最终一致性04：项目基础代码
好的架构其实是慢慢演变出来的，但良好的面向对象特性，一定是设计出来的。从图中可以看出，这里又为每个层次定义一个父类，并继承自BaseObject。例如BaseEntity表示所有实体类的父类，继承自BaseObject；BaseService表示所有服务类的父类，也继承自BaseObject。这样做可以将职责更加细化，可以参照Java中的集合类继承结构。
2023-02-27 15:00:00
298
原创 基于SpringCloud的可靠消息最终一致性03：项目骨架代码（下）
由于项目使用了MySQL、MongoDB、Redis、ActiveMQ、Nacos等中间件，这里就不一一安装了。基本骨架搭建完毕之后，下一步就可以开始充实内容了。
2023-02-26 11:00:00
472
原创 基于SpringCloud的可靠消息最终一致性02：项目骨架代码（上）
之前已经把分布式事务问题交代了一遍，包括两大定理、五大解决方案和一个成熟的开源框架，而咱们最终的目标是用SpringCloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。
2023-02-26 09:00:00
555
原创 基于SpringCloud的可靠消息最终一致性01：定理、解决方案和框架
很多同学都知道分布式事务很好很强大，而且互联网上也有很多分布式事务的相关理论和解决办法，例如CAP、BASE、2PC、TCC、XA、最大努力通知、柔性事务等等，但这些理论全都缺少完整的实际案例作为参考指引（这里说的「实际案例」，不是指的几段代码，或者一两个类文件，而是指从数据库设计到最后可以部署的完整项目），所以好多人也就不知道该怎么结合实际业务场景来实践它们。
2023-02-26 07:30:00
424
原创 JVM系统优化实践（4）：以支付系统为例
前面说过，JVM会将堆内存划分为年轻代、老年代两个区域。年轻代会将创建和使用完之后马上就要回收的对象放在里面，而老年代则将创建之后需要长期存在的对象放在里面。那么现在再来看一个比较具体的例子。
2023-02-26 07:30:00
379
原创 规则引擎与风控系统05：其他规则引擎
其实更复杂的基于规则的风控系统也都是从简单到复杂慢慢演化出来的。虽然Drools很强大，但它也不是唯一的规则引擎，还有另外两个也同样出色，它们是Groovy和Aviator。
2023-02-25 15:00:00
641
原创 规则引擎与风控系统04：风控系统实例（下）
上一节把风控实例的基础代码都撸了出来。接下来再来把核心服务代码和规则文件写出来。因为有了实体类、Dao，所以接来下就可以写服务类了。之前说过这个实例就是要实现两个目的：1、一分钟内连续访问三次以上，就会被直接封杀；2、黑名单用户登录会记录可疑事件。
2023-02-25 14:00:00
407
原创 规则引擎与风控系统03：风控系统实例（上）
就笔者个人创业经验，对小公司而言，最快最有效的风控手段可能就是「事件监控」和「黑名单」这两种了。原因就是简单好实现，而且实现成本几乎可以忽略不计。至于之前介绍的那些「标准/风控模型」，是在有了团队、技术及资金支持（也就是有钱了，有人了，可以想怎么折腾都行了）的情况下，才能着手实施的。而且「黑名单」也是基本上来源于「事件监控」。
2023-02-25 11:00:00
616
原创 规则引擎与风控系统02：规则引擎
由于运行规则总是会变来变去，而技术同学又不想每次规则变化就改一次代码然后变成地中海。也就是说，必须有一种技术手段，将活动规则和代码进行解耦，不管规则怎么变，代码都不用改。真有可以这么神奇么？——确实有一种这样的「解耦」技术，那就是「规则引擎」。所谓「规则引擎」，根据某百科的解释是：「是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。它接受数据输入，解释业务规则，并根据业务规则做出业务决策」。
2023-02-25 10:00:00
742
原创 规则引擎与风控系统01：新问题，新挑战
有些行为（比如薅羊毛）虽然没有病毒、木马、漏洞等攻击来的直接，但是如果一直被黑灰产（羊毛党、刷单党等）长期吸血，企业生存下来的几率也会很低，而且这些也会严重影响正常用户的体验和利益。基于此，互联网平台借鉴了金融行业中的「风控」（风险控制）机制，主要是对欺诈和作弊行为采取了有针对性的应对策略，而不再像过去那样只知道救火。
2023-02-25 07:30:00
460
elasticsearch常用命令脚本
2022-11-26
Spring boot Could not resolve placeholder
2017-09-08
TA创建的收藏夹 TA关注的收藏夹
TA关注的人