JSR-133/166内容解读

关于JSR-133规范(Java内存模型和线程规范)的部分内容解读 前言: 该规范对Java语言规范中的两项规范进行了更改(增强),基于也此促使了JVM对这两项规范内容的实现的修改。 ①Volatile关键字语义的增强,在原始的规范字这个语义是不具备有序性的,即允许指令的重排序。而在该规范中,Vol

Java多线程事务百万级数据插入实践

前言 看标题0v0 准备工作 1、建个SpringBoot项目,主要的依赖: <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <ar

Java多线程演进史

前言 在写下这篇文章的半个月前,我还在不断的反思自己的学习方式,质问自己为什么学不好多线程,为什么用不熟多线程。这个困扰我非常久的问题一直都没有得到解决,我刷过sgg、heima的线上课程,看过各种权威书籍,但是回过头来,我觉得自己完全没有基于这些知识梳理出一个可观测的知识体系。直到最近,我尝试从另

阿里巴巴Java开发手册整理

整理了一些参考价值比较高的规范。 编码方面 1、【强制】POJO 类中的任何布尔类型的变量,都不要加 is 前缀,否则部分框架解析会引起序列化错误。 说明:在本文 MySQL 规约中的建表约定第一条,表达是与否的变量采用 is_xxx 的命名方式,所以,需要在<resultMap>设置从 is_xx

Note for Jakarta Annotations 规范

前言: Jakarta EE从研究Spring框架所做的工作中获益良多。Jakarta EE规范可以采用并标准化Spring框架已经使之成为行业标准的技术和实践。了解为什么Spring对Jakarta EE很重要,以及Jakarta EE如何影响Spring! Jakarta Annotations

基于 EasyExcel + 线程池 + 批量插入实现百万级数据导入

背景 之前的项目中有一个数据迁移,原来的数据存储在旧的系统,现在系统做了重构,需要迁移到新的系统中,老系统的数据被加工到Excel中了,需要基于Excel实现文件的导入,同时需要避免内存溢出以及性能太低的问题。 问题分析 内存溢出问题 百万级别的数据量的 Excel 文件会非常大,如果全都加载到内存

中间件误区及高可用方案设计

一、MQ 问题1:消费者漏消息 说明:一般都是开发不当导致,只要利用好,是可以避免丢失消息的 漏消息场景: try catch将异常吞掉 redis锁使用不当 public class OrderCancelListener{ @Override public void onRece

对整个CI/CD流程提速的思考、经验总结。

开篇 总的来说,在我认知中的CI/CD流程,可以分为以下几大步: maven打包流程 镜像打包流程 镜像推送流程 镜像拉取流程 镜像启动流程 这几个步骤里可以进行更细一步的划分,当然,我在这篇文章里不会一 一去列举,对应的,我会直接点名流程中存在的,可以优化的点。 Maven打包流程 1、使用本地代

多线程并发编程实战避坑指南

1、“不正确的创建”线程池 常规来说,线程资源必须通过线程池提供,不允许在应用中自行显式创建线程,代码规范也明确表示 “线程资源必须通过线程池提供,不允许在应用中自行显式创建线程”,但是创建线程池的方式也有很多种,不能滥用。 常见创建线程池方式如:通过 JDK 提供的 ThreadPoolExecu

log4j2日志配置最佳实践

现状 各个应用日志策略比较混乱且没有统一的标准,存在大量重复日志输出以及日志滚动策略配置不合理等现象。 示例,包括但不限于: • additivity="false"导致部分日志无法传递给父Logger处理 • 无脑additivity="true"导致大量重复日志打印 • 滚动保留文件配置过大,单