首页
首页
AI Coding
NEW
沸点
课程
直播
活动
AI刷题
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
会员
登录
注册
开发实战技巧
Corbing
创建于2024-11-12
订阅专栏
开发实战技巧
等 19 人订阅
共18篇文章
创建于2024-11-12
订阅专栏
默认顺序
默认顺序
最早发布
最新发布
SpringBoot 注解式接口加解密
使用 @Crypto标记需要加解密的接口 配置中心, 支持动态开关和算法选择 算法扩展 , 可插拔的加密算法模块 消息处理 , 使用Spring的Advice机制处理请求
先删除后插入的并发问题
案例背景 背景:比如两个用户同时批量下发审批操作,审批的是同一批数据,并发调用用一个方法,方法中存在先删除后插入的操作,高并发情况下,可能会引发数据并发问题和死锁问题
基于AOP实现智能日志打印
一、文章前言 针于公司的项目,排查问题太慢,因为每个人的代码风格不一,日志的打印可能没有严格的要求,所以写以此篇,实现【请求日志打印】和【注解日志打印】两大功能,方便问题排查与日志记录。
👻优雅的数据转换工具:一站式解决数据处理
在当今复杂的业务场景中,数据的转换和处理几乎是每个项目都绕不开的话题。传统方式中,开发者往往需要编写冗长的代码来实现数据的拷贝、转换和加工,这不仅耗费时间,还容易出现错误.
🤕告别 if 第四讲(业务责任链)共四讲
在复杂的业务系统中,往往需要执行一系列操作,这些操作可能是条件驱动的,并且每个操作的执行顺序和条件可能都不同。为了更好地管理这些操作,我们可以利用 责任链模式 来实现一系列操作的顺序执行
🤕告别 if 第三讲(业务策略)共四讲
在公司进行业务开发中,随着业务的复杂性不断提升,开发者常常需要为不同的业务场景设计不同的策略。传统的做法往往依赖于条件判断或大量的 if-else 语句来实现策略的切换。
🤕告别 if 第二讲(业务执行器)共四讲
在实际开发中,if 语句常常是控制流的核心,但它们的滥用可能会导致代码冗长、可读性差,甚至引发维护问题。如何减少 if 语句的使用,使得代码更具可读性、可维护性,并提高开发效率
🤕告别 if 第一讲(业务断言)共四讲
在公司进行业务开发中,会涉及到很多的 if else,比如参数校验,数据缺失,逻辑判断等等,会让代码变得十分臃肿且不好维护,于是乎使用一个业务断言工具类,把一些 if 操作抽到断言工具类
🍓2025年最强打破并发魔咒!用Redisson自定义注解解锁分布式锁的神秘力量~
在这个流量为王的时代,每一次用户操作都可能触发千万级的并发访问,系统的稳定性成为每位开发者的终极战场。无论是电商大促、热门抢票还是社交平台的互动高峰,如何让你的系统在狂风暴雨中稳如泰山?
教你4步虚拟机扩容?
虚拟机环境 ubuntu 24.02,并且在已经给虚拟机新分配内存,但是没有生效,需要对虚拟机进行扩容。 开始扩容 使用lsblk输出磁盘分区 根据 lsblk 的输出,磁盘 /dev/sda 已经有
深入解析默认值工具类:DefaultUtil
在Java开发中,经常会遇到值为空(null)时如何处理的场景。在这种情况下,我们需要提供默认值来避免空指针异常(NPE)或其他潜在的错误。
jar 包 windows上运行,并且设置自启动
Windows bat 文件配置 运行该bat脚本需要保证windows上需要安装java环境,如下: 设置Windos服务自启动 新建bat快捷方式,如下: 路径上输入下面命令 把bat快捷方式拖到
2025年了一行实现策略模式
纳 ~ 有码有图有真相 下面是测试样例以及测试结果 调用等待中的对应策略实现 接下来我们进入真正实操体验 定义顶层策略接口 设计一个顶层策略接口,这个接口是需要进行功能实现的入口,你需要实现什么功能,
【世一枚举】2025年了原来枚举还能这样用
以前我们获取枚举类型 当我们想要获取短信类型为1(阿里云)的枚举类,以前我们需要这样做 2025年我们获取枚举类型 现在我们只需要两行!!!
💖2025年重生之我在学Stream流(强烈建议实操)
Stream流的特点和使用过程 Stream API允许开发者以声明性方式处理数据集合。可以简化复杂的数据操作,并且支持并行处理以提高性能。
使用Validation自定义Double类型属性校验
背景 新需求中由于我想使用Validation的校验注解实现对Double类型的参数进行条件限制 “不能小于0” ,但是发现Validation提供的注解都不满足我的使用场景
封装CompletableFuture并行处理工具类
前言 为了专注业务实现,我们采用 枚举 + CompletableFuture + 自定义线程池,封装了一套并行处理业务的工具类,便于在大数据和批处理场景中高效利用线程池。
2025年了请使用更加优雅的Bean注入(@Resource过时了)
日常开发发现 思考:大家看到如下代码,有发现什么问题呢? 是不是很多@Resource,造成不仅是代码的整洁度,还是代码观感,其实都不是很好,我们常常说尽量消除冗余代码,增强复用