深度Java

由于这张表非常大，加所以处理了5分钟。从10:56分开始A服务就一直等待B服务响应，加索引之前B服务响应是几十毫秒，加索引之后陆续增加到7秒，甚至更多，由于B服务自己又没有加超时机制，所以就一直等待。在我问A服务的研发之前，他们自己都说不清什么时候出问题，只是说大概11点多，从JVM线程监控看出问题的时间点是10:56分开始，11:00的时候线程已经打满。这里需要注意，因为有些请求一直没有返回所以一直在等待，后面是11:20分左右重启这些自然就没有记录到日志，这个日志是返回的时候才记录，所以存在缺陷。

这批文章重点讲数据库故障的排障思路，如何快速定位问题，恢复故障，并给出解决方案。：客户端电脑通过nginx访问网关，网关访问微服务，微服务调用下游，下游有其他微服务，中间件，数据库。：早上10点多微服务所有接口整体非常卡顿，延迟都在30毫秒以上，系统不可用。因为是Oracle数据库，其中有一个指标是可以被监控到的，Oracle节点之间延迟在1秒以上，正常情况下这个延迟是5ms以内。初步怀疑其中一个节点出现了问题。这边有必要介绍下Oracle的架构是双RAC+ADG。： 指的Oracle集群。

现象：线上两套环境配置都是虚拟机32核心CPU，整体数据库，中间件没有太大的差异。但是其中一套环境明显性能不如另一套。通过使用top命令按1查看每一个CPU核心的负载#top 按1很明显负载集中在前16核心上。通过采集每一个核心的si值监控长期运行曲线下图中突出就是一部分CPUsi值很高，处于压力高峰：查看同时期的CPU负载：系统负载：可以看出负载比较高，实际上一般CPU没有充分利用起来。还可以查看interrupts得到更加详细的CPU每一个核心的中断统计命令用于查看。

虚拟机因宿主机资源不足被剥夺的 CPU 时间占比。

这份 NMT 报告显示。

是 Linux 系统的“总控台”，它记录了内核、核心系统服务以及各种关键系统事件的广泛信息，是系统管理员进行监控、调试和维护的首要信息来源。（有时）包含 Heap 的简要信息（如分代大小、使用情况），但通常不是主要诊断点（因为 Heap OOM 一般不会导致 JVM 崩溃生成 hs_err）。），确定崩溃发生在 JVM 内部、JIT 编译的代码、还是你的 Java 代码调用的 JNI 本地方法。的致命错误（通常是底层原生代码问题、严重的资源耗尽如本地内存、JVM 内部错误、硬件问题等）而。

很多时候会面对线上内存使用很多，特别是本地内存怎么用的说不太清，就是每一块内存总和和总的Java线程占用内存不匹配。很多时候如果dump出来内存也没有太大的作用，因为本地内存是看不到。本地内存有很多是线程占用的空间。需要说明的是-Xss 参数为设置单个线程栈的大小, 一般默认为512K~1024K。

这是一个非常复杂的故障排查过程，也是非常有价值的经验分享。这是一个K8s环境，非常复杂的故障涌现过程，排障过程也很慌乱，整个过程现在整理起来看起来很轻松，不过当时却是另一番心情。......

线上一个项目线上3节点POD，内存一点点爬升最后100%打满，然后就会触发K8s的驱逐机制，重启。然后内存又是一点点的爬升周而复始，系统完全不可用。

本文讲述一个线上真实的案例，阿里云K8s容器Pod中Java进程CPU占比100%排查，也分享了不同的排查工具如何来排查这一问题。

Linus大师说他11岁就开始编程，他说他是一个喜欢安静和不合群的人。图中是他和他的弟弟，看来少儿编程还是很重要的，大师21岁写出linux0.0.1最初的内核。图中是他的家，也是Linux的总部，非常简单的办公环境，只有显示器，大师喜欢安静，所以不想听到电脑主机风扇声音，墙壁是绿色的，他觉得可以让他宁静。Linus说他认识很多在谷歌工作的人在家里都有小型数据...

XMX是JVM的最大堆内存大小。XMS是JVM的初始堆内存大小。如果你想快速得到一个答案：XMX和XMS设置为一样大，设置为系统最大内存的70%左右即可。先看参考java官方文档：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.htmlhttps://docs.oracle.c...

下面2段代码都是完成商品名称的更新，只是第一种情况数据源是list第二种是map第一代代码是从List里获取第0个entity.setProduct_name(productList.get(0).getName());第二段代码从map里获取键值entity.setProduct_name(productMap.get(pid).getName()));如果哪一天第一段代码修改了 然后忘记改第二段代码这是一种容易犯错的情况。更多的是改了第一段代码直接复制到第二段，也可以..

代码规范碎碎念list条件多于2不要写命名上controller (model-DTO)service (model)repository层 语义化构造(entity->model)String转map 语义化数据结构String转model 从数据库层增强语义 组装模型DAO ( entity)mapperVO(admin) DTO(client)---------facade层 必须接外部接口 必须用 integration包一层接口降级不...

因为MaxTenuringThreshold设置不合理，导致年轻代的对象很快进入年老代，导致年老代FGC频率增加，进而影响系统性能。

1.领域划分通用划分模式，一定的内聚，这并不难，难的还是领域直接的耦合怎么尽可能的解耦干净2.领域解耦错综复杂的调用关系分层，从顶到底，不允许底层调上层。底层需要的数据尽量上层提供，而不是底层继续调接口：性能问题，循环调用，等。3.代码翻译与义译基本是直接翻译，但是需要做一定的去重，原先代码因为是单体工程，所以会不断的查库，分层之后，需要的数据都已经上层给你提供，那么没必要做太多的if else这需要消除。例如：某方法 原先是 需要根据商品id区分是自己从购物...

系统架构如果设计之初就设计错了，那么必然是南辕北辙。系统分为三层，数据层 视图层 业务层数据层 包含数据存储和数据交互，应该是纯数据操作和业务无关业务层 自然就是service层这是最多变的一层视图层 接口那么系统设计应该按照什么顺序呢？应该是先设计数据层，如果数据层设计错了那么整体就会事倍功半。所以这是一个自底往上的过程。但是，上并不是到业务层，而是视图层，因为你的一切设计都是围绕对外，如果你的接口没有使用使用价值整个系统也就变得没有价值。好，当你设计好视图和数..

产品 开发 测试 三者都理解不一致。产品怎么样表达出自己的诉求，是否写清文档就够了。开发觉得自己沟通了，但是为什么测试一提测又许多问题。测试的case看似都一起评审了。而这样的结果必然是重新修修补补，怎么样事前把问题全部解决？产品的设计稿，开发的代码，测试的case 不统一是关键！...

一个需求 如果你一开始的出发点就错了，那么后续的设计只会非常复杂，而且还会有漏洞，也很难发现，发现了也很难解决。先看数据结构：A表 主键id 其他各种字段不重要 ，重要的就一个字段sort字段aid1 sort=1aid2 sort=1---------------------B表 A的关联表 存A的id 还有就是C表的idaid1 cid1aid2 cid2-------------------C表 某种数据cid1cid2...

经常是某司线上又出bug了，然后是给公司造成多少损失，追根究底总是可以找到一些原因，诸如：写代码逻辑考虑不全面，或者代码有硬伤，也有测试不充分，甚至不测试都有，也有是运维的问题等等。我对测试部专业，测试是否可以发现所有问题我不好说，但是可以肯定的是从很多大厂出过的问题来看，测试只能减少问题，不能彻底规避问题。可能你会说需要监控等手段并用，那是必须的，但是首先还是需要把代码写好。作为开发人员需要有些追求，写出高阶一点的代码，不然只是这次发现问题，但是一些不好的习惯或者代码水平不提高还是会出错。