文章列表

2.2k字2 分钟

# 前言 最近电商 618 活动，12600KF 价格非常诱人，叠加优惠券只需 820 元。虽然很想入手，但考虑到我使用双屏且不喜欢关机，还是决定保留核显以降低待机功耗。因此，我们今天来探讨如何将 i5-12400 超频到接近 12600K 的性能水平。 # 系统配置 操作系统: Windows 11 专业版 64 位 (版本 22631.3737, 23H2) 处理器: Intel Core i5-12400 (6 核 12 线程，Intel 7 工艺) 显卡: 集成显卡: Intel UHD Graphics 730 独立显卡: NVIDIA GeForce RTX 2080 Ti
3.3k字3 分钟

# Shoka 升级 玩 blog 开始就用的 Shoka, 一直都没管主题，今天偶然发现别人的 Shoka 和我的长得有点区别，看页脚，ShokaX, 诶诶，居然有 ShokaX, 随后检索，发现原来 Shoka 已经停更了三年了 看了一下 ShokaX, 感觉优化了不少东西，直接升呗 npm -g install shokax-cli SXC install shokaX -pm npm # [SXEC 102] Critical rendering plugins are missing or incorrectly configured. 此代码代表包安装不完整，关键插件未安装，可
3.9k字4 分钟

# 背景介绍 在一个项目中，我们使用了其他同事提供的 websocket 代码。项目接近测试结束阶段时，我对代码进行了审查，发现 IDE 提示当前使用的 websocket 版本存在 CVE 漏洞。起初认为这可能只是一个小问题，只需要简单地升级版本就能解决。然而，事实证明这个过程比预想的要复杂得多。 # 使用的开源组件：org.java-websocket 原始依赖版本是 1.3.0： <dependency> <groupId>org.java-websocket</groupId> <artifactId>Java-We
2.6k字2 分钟

# 背景 最近开发了一个特性，关于 websocket 的功能，代码量直接给感到了 5k, 联调都好了，程序就挂在服务器上，然后就没管了，今天发现这个服务器，卡卡的，一看 CPU 占用 500%, 惊了 # 定位 # 先看哪个线程这么吃 CPU top -Hp pid, 这个是查看线程，直接 top 显示的都是进程 然后取 CPU 占用最高的一个，printf “% x\n” 线程号， 再用 jstack pid > stack.txt 在 stack.txt 里面检索一下，发现是 GC 的线程，看了 CPU 占用最高的几个线程，都是 GC 的，然后突然发现端倪，为什么 Thread
5.7k字5 分钟

# 背景 测试那边转过来一个问题单，开发这边初步定位是 struts 框架接收集合参数只能接收到 256 个 # 定位 # google 一下 先直接 google 了一下，感觉回答有点偏，说是 struts2.5.15 升级到 2.5.30 就会有这个问题，是 struts 改用 ArrayList 的 TypeConverter, 我自己去代码里面看根本咩有限制 public Object convertValue(Map<String, Object> context, Object target, Member member, String propertyName, O
1.4k字1 分钟

# OOM 的原因 # 申请了大量的对象 写查询语句，不加 limit, 直接查到全表了 <select> select id, name, .... from user <where> <if test='name !=null && name!='''> name = #{name} </if> </where> </select
1.3k字1 分钟

# 前言 本文将指导您如何在 Windows 系统上安装 Docker, 并使用 Docker 来运行 Redis 容器。这种方法比直接在 Windows 上安装 Redis 更加简单和灵活。 # 安装 Docker Desktop for Windows 系统要求: Windows 10 64 位: Pro, Enterprise 或 Education (Build 16299 或更高版本) 启用 Hyper-V 和容器功能 下载 Docker Desktop: 访问 Docker 官网 点击 "Download for Windows" 下载安装程序
1.4k字1 分钟

# 背景 在话务量环境中，我们发现接口响应变慢。由于该环境中运行着多种业务，难以直接判断是哪个业务引发了这个问题。因此，我们需要进行深入的性能分析和问题定位。 # 问题定位过程 # 1. 使用 jstat 观察垃圾收集情况 首先，我们使用 jstat -gcutil 命令查看垃圾收集的情况。观察结果显示： 老年代使用率较高 GC 次数和时间明显偏多 这些迹象表明系统可能正在频繁进行 Full GC。 # 2. 使用 jmap 分析堆内存 接下来，我们使用 jmap -heap <pid> 命令查看堆内存使用情况，发现内存使用量确实很高。 为了进一步分析，我们执行了以下步骤：