Java

Java 后端开发者理解 Vue：从 Controller 思维到响应式 UI 如果你已经会 Java，熟悉 Spring、Controller、Service、DTO、Repository、拦截器、配置文件和请求响应链路，那么你看 Vue 代码时，大概率不是“完全看不懂”。你能看懂变量、函数、条件判断、数组遍历，也大概知道 <div>、<span>、class、@click、:disabled 在页面上会产生某些效果。 真正的问题通常不在“语法完全陌生”，而在于：你会不自觉用后端的心智模型去解释前端。 你可能会把 .vue 文件里的 <template> 当成类似 Spring XML、JSP、Thymeleaf 的配置或模板；会把 props 理解成 DTO 字段；会把 emit() 想成直接调用父组件方法；会把 v-model 想成子组件直接修改父组件变量；会把页面更新理解成“重新请求一次接口然后刷新页面”。这些直觉有一部分能帮你入门，但在 Vue 的核心机制上会误导你。 本文的目标不是泛泛讲 Vue，而是站在 Java/Spring 后端开发者的视角，把最容易困惑的部分拆开：Vue 页面为什么会自动刷新、ref() 和 .value 到底是什么、v-model 双向绑定是不是魔法、:xxx 和 @xxx 为什么不是普通 XML 属性、组件之间为什么要 props 向下 emit 向上，以及 Element Plus 组件、插槽、scoped CSS、:deep() 这些东西应该如何理解。 1. 先纠正一个根本误区：Vue 页面不是一次请求生成一次响应 后端开发者最熟悉的链路通常是： HTTP 请求 -> Controller -> Service -> Repository / Mapper -> 返回 JSON 或 HTML -> 本次请求结束 这个模型的核心是“一次请求，一次处理，一次响应”。 ...

Java 性能问题定位：从系统指标到应用排查 参考阿里云大佬的博客，大佬写的非常好 本文整理 Java 应用在实际线上环境中进行性能问题定位时常见的分析思路，主要从业务代码、CPU、线程、内存、GC、磁盘 I/O、网络 I/O 以及常用命令几个角度展开。 性能问题往往不是单一指标异常导致的，而是系统层、组件层和应用层相互影响后的结果。因此，排查时建议先从应用层入手，再结合系统指标进行验证。 性能优化工具图谱 ├── 系统层 │ ├── CPU │ │ ├── 🚩 CPU利用率（top/vmstat/sar/dstat） │ │ ├── 🚩 CPU平均负载（top/uptime） │ │ └── 上下文切换次数（pidstat/vmstat/dstat） │ ├── 内存 │ │ ├── 全局内存使用 │ │ │ ├── 🚩 已用/剩余/可用内存（free/vmstat/sar） │ │ │ └── 缓冲区/缓存（pcstat/cachestat/cachetop） │ │ └── 进程内存使用 │ │ ├── 🚩 虚拟内存/常驻内存/共享内存（top/ps/pidstat） │ │ ├── 🚩 SWAP 内存使用/换入换出速度（top/free/vmstat/sar） │ │ ├── 缺页异常（ps/pidstat） │ │ └── 内存分布（pmap/jmap） │ ├── 磁盘 │ │ ├── 空间容量（df/du） │ │ ├── 🚩 吞吐量/磁盘 I/O 使用率（iostat/dstat/sar） │ │ └── 缓冲区/缓存（pcstat/cachestat/cachetop） │ └── 网络 │ ├── 🚩 吞吐量（sar） │ ├── 网络延迟（ping） │ ├── 🚩 网络连接数/错误数（netstat/ss/sar） │ └── 网络抓包（tcpdump/wireshark） ├── 组件层 │ ├── 数据库 │ │ ├── SQL 调优 │ │ ├── 🚩 索引调优 │ │ └── 连接池配置 │ ├── 网络 IO │ │ ├── I/O 调度模型 │ │ ├── 序列化框架 │ │ └── 线程调度模型 │ ├── Web 容器 │ │ └── 线程池配置 │ └── 缓存/MQ…… └── 应用层 ├── 线程 │ ├── 死锁检查（jstack/arthas） │ ├── 🚩 线程状态分布（jstack/arthas） │ ├── 锁竞争分布（jstack/arthas） │ ├── 🚩 代码执行热点（jprofiler/zprofiler） │ ├── 🚩 占用 CPU 较重的线程（top + pidstat + jstack） │ └── 代码追踪（btrace/housemd/greys/arthas） ├── 内存 │ ├── 内存分配 │ │ ├── 常驻内存/虚拟内存（top） │ │ ├── 对象分配热点（jprofiler/zprofiler） │ │ ├── 🚩 堆内对象分布（jmap/zprofiler/MAT） │ │ ├── 类加载相关（jstat/greys/arthas） │ │ ├── 🚩 内存泄漏（gperf/MAT/zprofiler） │ │ └── 堆外内存（jmap + MAT + NMT + gdb + perf） │ └── 垃圾回收 │ ├── GC 线程使用（jinfo） │ ├── 对象晋升年龄（gclog） │ ├── 🚩 GC 的频率和时间（jstat/gclog） │ ├── 垃圾回收器类型/JVM 参数（jinfo/jcmd） │ └── 🚩 堆大小设置及分区大小（jinfo/jstat） ├── 网络 │ ├── 带宽使用 │ ├── 流量异动 │ └── 网络分区 └── ★ 业务（日志、监控…） ├── 🚩 代码逻辑 ├── 远程调用 └── 架构设计 CPU&&线程 和 CPU 相关的指标主要有以下几个。常用的工具有 top、 ps、uptime、 vmstat、 pidstat等。 ...

设计模式 举个例子，比如我们有个导出功能，按照不同的格式导出数据，比如 CSV、Excel、JSON 等；比如我们需要导入 execl 文件，需要解析文件内容，针对不同的格式，需要不同的解析方式；再比如我们有一个给用户发送邮件功能，有可能需要用 gmail, qq, 163 等邮箱服务商，手机验证码服务也是如此。如果我们使用 if-else 或者 switch-case 来实现，代码会变得很臃肿，而且扩展性很差，多一个导出为其他格式的需求，就需要大量修改代码。 处理之前的代码可能长这样： /** * @param filePath 文件路径（含文件名） * * 导出 CSV 和 Excel 的需求 */ public void export(String filePath) { String fileType = filePath.substring(filePath.lastIndexOf(".") + 1); if ("csv".equals(fileType)) { // 导出 CSV 的具体代码，以下省略100行 } else if ("excel".equals(fileType)) { // 导出 Excel 的具体代码，以下省略100行 } else { throw new IllegalArgumentException("不支持的文件类型：" + fileType); } } 策略模式 策略模式的主要作用是用来提升一些代码的复用性的，或者解决代码中出现很多 if-else 语句的问题。 ...