之前的Idea正版激活码到期后，我来更新一下破解版的操作，此版本适应于 IDEA 2023.3，低版本可以使用30天无限重置激活，废话不多说，直接上破解教程。



# Mac IDEA 2023.3 破解

## 下载破解包
链接: https://pan.baidu.com/s/1OdSP8XSH6larmGpUMPuVpg 
提取码: w3u2 
复制这段内容后打开百度网盘手机App，操作更方便哦

## 确认路径
此破解包安装后，会改变Mac系统的环境变量，且不能被删除（一旦破解包被误删， Idea启动就会报错），所以启动时一定确认好，我是将此破解包放到了IntelliJ IDEA.app 的包内容下

![image.png](/static/img/fa87e3de3969d6708b80af7529a9c8e0.image.webp)

## 修改破解包配置

### 修改 install.sh

![image.png](/static/img/d2f21644d2951630fbbb508cf683d046.image.webp)

将 BASE_PATH 的路径，修改为上面环节确认的路径
```sh
BASE_PATH="/Applications/IntelliJ IDEA.app/Contents/jetbra"
```

### 修改 idea.vmoptions

![image.png](https://blog.liushigong.cn/static/img/9be25916f052f4d9b077dcd9773eefad.image.webp)

将 -javaagent 路径修改为上面环节确认的路径

```sh
-javaagent:/Applications/IntelliJ IDEA.app/Contents/jetbra/ja-netfilter.jar=jetbrains
```

## 安装破解包

新建终端，打开上面环节确认的路径

![image.png](/static/img/6be2db2398ee03bd4e2f5986da657054.image.webp)

启动脚本
```sh
sudo bash ./install.sh
```

提示 `done. the "kill Dock" command can fix the crash issue.` 即为成功

![image.png](/static/img/567165e67810dc0372db4e184f555119.image.webp)

重启系统，命令`env`查看环境变量（重启以后的效果如下）：

![image.png](/static/img/430b77588fb8309e2f0014d1db5349dd.image.webp)


:::tip{title=""}
<span style="color:red">**成功后，Mac 系统的环境变量需要重启才会生效**</span>
:::


部分小伙伴 Mac 系统执行脚本遇到如下错误：

`sed: RE error: illegal byte sequence`

执行以下命令以后即可。
```sh
export LC_COLLATE='C'
export LC_CTYPE='C'
```

### 配置激活码

电脑重启以后，打开Idea，填入以下激活码激活即可。

    6G5NXCPJZB-eyJsaWNlbnNlSWQiOiI2RzVOWENQSlpCIiwibGljZW5zZWVOYW1lIjoic2lnbnVwIHNjb290ZXIiLCJhc3NpZ25lZU5hbWUiOiIiLCJhc3NpZ25lZUVtYWlsIjoiIiwibGljZW5zZVJlc3RyaWN0aW9uIjoiIiwiY2hlY2tDb25jdXJyZW50VXNlIjpmYWxzZSwicHJvZHVjdHMiOlt7ImNvZGUiOiJQU0kiLCJmYWxsYmFja0RhdGUiOiIyMDI1LTA4LTAxIiwicGFpZFVwVG8iOiIyMDI1LTA4LTAxIiwiZXh0ZW5kZWQiOnRydWV9LHsiY29kZSI6IlBEQiIsImZhbGxiYWNrRGF0ZSI6IjIwMjUtMDgtMDEiLCJwYWlkVXBUbyI6IjIwMjUtMDgtMDEiLCJleHRlbmRlZCI6dHJ1ZX0seyJjb2RlIjoiSUkiLCJmYWxsYmFja0RhdGUiOiIyMDI1LTA4LTAxIiwicGFpZFVwVG8iOiIyMDI1LTA4LTAxIiwiZXh0ZW5kZWQiOmZhbHNlfSx7ImNvZGUiOiJQUEMiLCJmYWxsYmFja0RhdGUiOiIyMDI1LTA4LTAxIiwicGFpZFVwVG8iOiIyMDI1LTA4LTAxIiwiZXh0ZW5kZWQiOnRydWV9LHsiY29kZSI6IlBHTyIsImZhbGxiYWNrRGF0ZSI6IjIwMjUtMDgtMDEiLCJwYWlkVXBUbyI6IjIwMjUtMDgtMDEiLCJleHRlbmRlZCI6dHJ1ZX0seyJjb2RlIjoiUFNXIiwiZmFsbGJhY2tEYXRlIjoiMjAyNS0wOC0wMSIsInBhaWRVcFRvIjoiMjAyNS0wOC0wMSIsImV4dGVuZGVkIjp0cnVlfSx7ImNvZGUiOiJQV1MiLCJmYWxsYmFja0RhdGUiOiIyMDI1LTA4LTAxIiwicGFpZFVwVG8iOiIyMDI1LTA4LTAxIiwiZXh0ZW5kZWQiOnRydWV9LHsiY29kZSI6IlBQUyIsImZhbGxiYWNrRGF0ZSI6IjIwMjUtMDgtMDEiLCJwYWlkVXBUbyI6IjIwMjUtMDgtMDEiLCJleHRlbmRlZCI6dHJ1ZX0seyJjb2RlIjoiUFJCIiwiZmFsbGJhY2tEYXRlIjoiMjAyNS0wOC0wMSIsInBhaWRVcFRvIjoiMjAyNS0wOC0wMSIsImV4dGVuZGVkIjp0cnVlfSx7ImNvZGUiOiJQQ1dNUCIsImZhbGxiYWNrRGF0ZSI6IjIwMjUtMDgtMDEiLCJwYWlkVXBUbyI6IjIwMjUtMDgtMDEiLCJleHRlbmRlZCI6dHJ1ZX1dLCJtZXRhZGF0YSI6IjAxMjAyMjA5MDJQU0FOMDAwMDA1IiwiaGFzaCI6IlRSSUFMOi0xMDc4MzkwNTY4IiwiZ3JhY2VQZXJpb2REYXlzIjo3LCJhdXRvUHJvbG9uZ2F0ZWQiOmZhbHNlLCJpc0F1dG9Qcm9sb25nYXRlZCI6ZmFsc2V9-SnRVlQQR1/9nxZ2AXsQ0seYwU5OjaiUMXrnQIIdNRvykzqQ0Q+vjXlmO7iAUwhwlsyfoMrLuvmLYwoD7fV8Mpz9Gs2gsTR8DfSHuAdvZlFENlIuFoIqyO8BneM9paD0yLxiqxy/WWuOqW6c1v9ubbfdT6z9UnzSUjPKlsjXfq9J2gcDALrv9E0RPTOZqKfnsg7PF0wNQ0/d00dy1k3zI+zJyTRpDxkCaGgijlY/LZ/wqd/kRfcbQuRzdJ/JXa3nj26rACqykKXaBH5thuvkTyySOpZwZMJVJyW7B7ro/hkFCljZug3K+bTw5VwySzJtDcQ9tDYuu0zSAeXrcv2qrOg==-MIIETDCCAjSgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAYMRYwFAYDVQQDDA1KZXRQcm9maWxlIENBMB4XDTIwMTAxOTA5MDU1M1oXDTIyMTAyMTA5MDU1M1owHzEdMBsGA1UEAwwUcHJvZDJ5LWZyb20tMjAyMDEwMTkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUlaUFc1wf+CfY9wzFWEL2euKQ5nswqb57V8QZG7d7RoR6rwYUIXseTOAFq210oMEe++LCjzKDuqwDfsyhgDNTgZBPAaC4vUU2oy+XR+Fq8nBixWIsH668HeOnRK6RRhsr0rJzRB95aZ3EAPzBuQ2qPaNGm17pAX0Rd6MPRgjp75IWwI9eA6aMEdPQEVN7uyOtM5zSsjoj79Lbu1fjShOnQZuJcsV8tqnayeFkNzv2LTOlofU/Tbx502Ro073gGjoeRzNvrynAP03pL486P3KCAyiNPhDs2z8/COMrxRlZW5mfzo0xsK0dQGNH3UoG/9RVwHG4eS8LFpMTR9oetHZBAgMBAAGjgZkwgZYwCQYDVR0TBAIwADAdBgNVHQ4EFgQUJNoRIpb1hUHAk0foMSNM9MCEAv8wSAYDVR0jBEEwP4AUo562SGdCEjZBvW3gubSgUouX8bOhHKQaMBgxFjAUBgNVBAMMDUpldFByb2ZpbGUgQ0GCCQDSbLGDsoN54TATBgNVHSUEDDAKBggrBgEFBQcDATALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBABqRoNGxAQct9dQUFK8xqhiZaYPd30TlmCmSAaGJ0eBpvkVeqA2jGYhAQRqFiAlFC63JKvWvRZO1iRuWCEfUMkdqQ9VQPXziE/BlsOIgrL6RlJfuFcEZ8TK3syIfIGQZNCxYhLLUuet2HE6LJYPQ5c0jH4kDooRpcVZ4rBxNwddpctUO2te9UU5/FjhioZQsPvd92qOTsV+8Cyl2fvNhNKD1Uu9ff5AkVIQn4JU23ozdB/R5oUlebwaTE6WZNBs+TA/qPj+5/we9NH71WRB0hqUoLI2AKKyiPw++FtN4Su1vsdDlrAzDj9ILjpjJKA1ImuVcG329/WTYIKysZ1CWK3zATg9BeCUPAV1pQy8ToXOq+RSYen6winZ2OO93eyHv2Iw5kbn1dqfBw1BuTE29V2FJKicJSu8iEOpfoafwJISXmz1wnnWL3V/0NxTulfWsXugOoLfv0ZIBP1xH9kmf22jjQ2JiHhQZP7ZDsreRrOeIQ/c4yR8IQvMLfC0WKQqrHu5ZzXTH4NO3CwGWSlTY74kE91zXB5mwWAx1jig+UXYc2w4RkVhy0//lOmVya/PEepuuTTI4+UJwC7qbVlh5zfhj8oTNUXgN0AOc+Q0/WFPl1aw5VV/VrO8FCoB15lFVlpKaQ1Yh+DVU8ke+rt9Th0BCHXe0uZOEmH0nOnH/0onD
    
![image.png](/static/img/0121ab5d9e0dcb40a4e6cc905869a413.image.webp)


激活日期到2025年8月，完美！

![image.png](/static/img/fab4e14a469a3b2e4160b4c2d1b27cf2.image.webp)

Mac IntelliJ IDEA 2023.3破解激活

整理一些阅读过的与收集的电子书籍



## 微服务

[《分布式服务架构.原理、设计与实战》](https://pan.quark.cn/s/c9c6e553eafd)

[《分布式文章汇总 v1.2 2021-03-23》](https://pan.quark.cn/s/8e11d4317fac)

[《深入分布式缓存 - 从原理到实践-完整版(带标签)》](https://pan.quark.cn/s/df627b816937)

[《Spring Cloud微服务全栈技术与案例解析》](https://pan.quark.cn/s/174887bc7fba)

[《Spring+Cloud与Docker微服务架构实战》](https://pan.quark.cn/s/6ad6ab7e7ff9)

## 提升功力

[《亿级流量网站架构核心技术》](https://pan.quark.cn/s/a95004051269)

[《深入理解Java虚拟机：JVM高级特性与最佳实践(第三版)》](https://pan.quark.cn/s/d2a5c5412590)

[《阿里工程师的自我修养》](https://files.alicdn.com/tpsservice/a3eafb12d315e3363de1e7dfd1daa0b7.pdf?spm=a2c4e.10696291.0.0.3e9d19a41uFUms&file=a3eafb12d315e3363de1e7dfd1daa0b7.pdf)

[《阿里巴巴 Java 开发手册 1.4.0》](https://ucc.alicdn.com/download/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4Java%E5%BC%80%E5%8F%91%E6%89%8B%E5%86%8C1.4.0.pdf)

[《设计模式之禅》](https://pan.quark.cn/s/1bcd447ac679)

[《大话数据结构》](https://pan.quark.cn/s/019241020062)

[《Spring 5核心原理与30个类手写实战》](https://pan.quark.cn/s/b33c4db659bc)

[《Spring源码深度解析（第2版）》](https://pan.quark.cn/s/286b31f6fe54)

[《SpringBoot学习笔记完整教程》](https://pan.quark.cn/s/d0a4acd7998f)

[《Docker中文手册》](https://pan.quark.cn/s/f721bf18c019)

[《阿里巴巴 DevOps 实践手册》](https://pan.quark.cn/s/0e8a5286d1fe)

[《鸟哥的linux私房菜_基础学习篇（第三版）》](https://pan.quark.cn/s/946c35bb6109)


## 中间件

[《Redis深度历险：核心原理和应用实践》](https://pan.quark.cn/s/2c10148e422b)

[《Redis开发与运维(完整版)》](https://pan.quark.cn/s/35f04b8819b2)

[《RabbitMQ系列教程》](https://pan.quark.cn/s/d4578c0b9696)

[《Redis 高手心法-码哥字节原创》](https://pan.quark.cn/s/d070ded7d89a)

[《Redis最佳实践与实战指南(阿里云出品)》](https://pan.quark.cn/s/b6bcf4c9a65e)

[《Rocketmq源码解析》](https://pan.quark.cn/s/40a74636d87c)

## Mysql

[《深入MySQL实战(阿里云出品)》](https://pan.quark.cn/s/7cad5afe831a)

[《高性能MySQL》](https://pan.quark.cn/s/e45129b39bb2)


## 并发编程

[《AVA并发编程实战》](https://pan.quark.cn/s/fa205d47fb76)

[《实战Java高并发程序设计》](https://pan.quark.cn/s/08e2fefb81fa)


## 面试相关

[《Java面试题合集最新版(485页)》](https://pan.quark.cn/s/fc14d50ad333)

[《JAVA面试核心知识点整理(283页)》](https://pan.quark.cn/s/e640785564ca)

[《互联网大厂面试题库大全》](https://pan.quark.cn/s/f019d87bacba)

[《程序员面试宝典-阿里出品》](https://pan.quark.cn/s/89e13b0ae2f5)

[《Java开发手册-灵魂13问(阿里出品)》](https://pan.quark.cn/s/867199916879)

## 全栈

[《Vue.js全家桶零基础入门到进阶项目实战》](https://pan.quark.cn/s/d739b9854550)

我的图书室

生产中出现了 `org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only` 异常，结合源码分析下原因




# Spring 事务源码分析

## 示例

代码之间的调用如下

```java
    @Transactional(rollbackFor = Exception.class)
    public void test() {
        // 测试出现 "Transaction rolled back because it has been marked as rollback-only"
        try {
            logService.testRockBack();
        } catch (Exception e) {
            System.out.println("try catch Exception : " + e.getMessage());
        }
    }
    
    
    @Override
    @Transactional(rollbackFor = Exception.class)
    public void testRockBack() {
        int i = 0;
        System.out.println(1/i);
    }
```

接口调用后，出现以下异常

![image.png](/static/img/b688dd2eba11571c5d581c5d7be0c98d.image.webp)


### 问题原因

在多个方法都有 `@Transactional`注解，A调用B，且把B的调用进行了try-catch


### 分析

从源码中开始分析，在 `AbstractPlatformTransactionManager #processRollback` 中，设置 `unexpectedRollback` 为 true 时，才会抛出此异常

![image.png](/static/img/1d55cdb2f359ca6c6da676fd221cf2d5.image.webp)


继续查看源码的调用栈，找到其 `processRollback(defStatus, true)` 方法处调用，入参为 true，那正常应该为不会调用到此方法，为什么此处会调用到呢？

我们接着分析下 `!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()` 这个判断条件


```java
    /**
     * This implementation of commit handles participating in existing
     * transactions and programmatic rollback requests.
     * Delegates to {@code isRollbackOnly}, {@code doCommit}
     * and {@code rollback}.
     * @see org.springframework.transaction.TransactionStatus#isRollbackOnly()
     * @see #doCommit
     * @see #rollback
     */
    @Override
    public final void commit(TransactionStatus status) throws TransactionException {
        if (status.isCompleted()) {
            throw new IllegalTransactionStateException(
                            "Transaction is already completed - do not call commit or rollback more than once per transaction");
        }

        DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status;
        if (defStatus.isLocalRollbackOnly()) {
            if (defStatus.isDebug()) {
                    logger.debug("Transactional code has requested rollback");
            }
            processRollback(defStatus, false);
            return;
        }

        if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
            if (defStatus.isDebug()) {
                    logger.debug("Global transaction is marked as rollback-only but transactional code requested commit");
            }
            processRollback(defStatus, true);
            return;
        }

        processCommit(defStatus);
    }

```


查看方法源码 `shouldCommitOnGlobalRollbackOnly()` 的实现底层，发现默认返回 false，那么此判断条件中一定为 true, 不会影响判断结果，核心的问题还是出现在 `defStatus.isGlobalRollbackOnly()` 的校验上，我们继续分析此方法

![image.png](/static/img/ab3bd73c9c220aa9a751c990563f068f.image.webp)


通过断点，可以确认此处判断调用到 `DataSourceTransactionManager #isRollbackOnly` 方法，其核心的 `rollbackOnly` 参数为 true，所以上述的逻辑判断中才会执行进程回滚的动作


![image.png](/static/img/83ad058e9d3abed168525012472725ca.image.webp)

![image.png](/static/img/ed2104f313fc0481ffe8bafc1dc39ff3.image.webp)


上述已然了解参数的定义，接下来查找下源码中如何设置成 true，从源码中发现如下代码设置为true

```java
    /**
     * Mark the resource transaction as rollback-only.
     */
    public void setRollbackOnly() {
        this.rollbackOnly = true;
    }
```

查看代码的引用，发现一个熟悉的调用 `DataSourceTransactionManager #setRollbackOnly`

```java
    public void setRollbackOnly() {
        getConnectionHolder().setRollbackOnly();
    }  
```

![image.png](https://blog.liushigong.cn/static/img/f2944cb53c962c8811e475cf331973bf.image.webp)


从堆栈中查看调用信息，发现又回到了老朋友 `#processRollback` 方法上，

![image.png](https://blog.liushigong.cn/static/img/953f7915fa750dcc56443dcee5e8bc0a.image.webp)

此处有个判断 `status.hasTransaction()` 结果为 true，表示存在事务，在这做个事务源码的延伸，这部分为多个事务之间嵌套的处理，源码处理的位置如下

![image.png](https://blog.liushigong.cn/static/img/4cc1892cba6a84c9e747e836a2a154e6.image.webp)


继续查找堆栈信息，可以找到 `completeTransactionAfterThrowing` 方法

![image.png](/static/img/a9ee0e024c86a951cb4a32141dcec6c7.image.webp)

继续往上，就看到这是 `try catch` 部分，我们都知道事务底层实现就是aop，由于此问题出现的原因是嵌套事务，且嵌套中的事务抛出异常，当异常抛出后，就会被捕获，且将底层 `rollbackOnly` 设置为 true，此时接下来回归到到主线上调用 `commitTransactionAfterReturning` 方法进行提交

![image.png](/static/img/91f879acc6753b7502c5cecf5cdd60c5.image.webp)


其实走到这就很明朗了，此处代码已经是文章开头追溯的那部分源码

![image.png](/static/img/84287a5c3302beb547f42acf57164410.image.webp)


## 总结

梳理下源码的流程，当嵌套内事务抛出异常时，会将**全局仅回滚标记** `rollbackOnly = true` 设置为 true, 从源码的正常流程来说会把异常继续 throw，但是当我们外层事务 `try catch` 后，就导致异常无法抛出，最外层事务在执行后续 `commit` 时，会校验是否为**全局回滚参数**，抛出 `throw new UnexpectedRollbackException("Transaction rolled back because it has been marked as rollback-only")`;

![image.png](https://blog.liushigong.cn/static/img/5f37493125d6c6c73ecf6f57406591ea.image.webp)

Spring 多重事务嵌套产生的异常

在开发的过程中，使用事务与锁是解决一些问题最常用的方式，但是当这俩个结合起来你真的会用吗？在高并发的场景下会出现哪些问题？要如何避免这些问题？接下来，带你了解事务与锁之间真正的打开方式。



# 示例

开发过程中，扣减库存是最经典的场景之一，接下来以此场景模拟扣减库存的代码实现


## 场景模拟

```java
// 实体
@Data
public class MaterialStock {

    /**
     * 物料库存id
     */
    private Long id;

    /**
     * 物料名称
     */
    private String name;

    /**
     * 库存数量
     */
    private Long stockNum;
}
```

```java
// 加锁 - 此处等同于分布式锁
ReentrantLock lock = new ReentrantLock();

// 实现方法
@SneakyThrows
@Override
@Transactional
public void updateById(Long id) {
    lock.lock();

    try {
        // 查询物料库存，扣减，然后更新库存
        MaterialStock materialStock = materialStockMapper.selectById(id);
        Long stockNum = materialStock.getStockNum();
        if (materialStock.getStockNum() <= 0) {
            log.info("库存不足");
            return;
        }
        materialStock.setStockNum(stockNum - 1);
        materialStockMapper.updateById(materialStock.getId(), materialStock.getStockNum());
        log.info("当前库存数量:{}\t，更新后库存数量:{}", stockNum, materialStock.getStockNum());

        // 其他处理，耗时 500ms
        TimeUnit.MILLISECONDS.sleep(500);
    }finally {
        // 释放锁
        lock.unlock();
    }
}

```

```java
// 单元测试
public void test3(){
    for (int i = 0; i < 30; i++) {
        new Thread(() -> customExecutorService.updateById(1L)).start();
    }
}
```

接下来，模仿并发下的场景，设置20个库存，使用30个线程同步进行扣减，查看库存扣减的情况

![image.png](/static/img/17122a07c22211fffc8c8442411cd22e.image.webp)

可以发现，库存中出现了少扣的情况，按照我们预想的执行，流程上应该是【加锁 -> 查询库存 -> 扣减库存 -> 更新库存 -> 释放锁】，数据上【线程数 30 - 库存数 20 = 剩余库存数 10】

现在看来，锁应该是失效了，那这是怎么回事呢？

## 代码分析

首先分析，一定是在【查询库存】的环节异常，将上次扣减的库存查询出来，那出现这种情况只有两种可能性，一种是【加锁】环节没有生效，一种就是【更新库存】没有执行成功，目前代码上加锁逻辑没有任何问题，那么出现问题的就只能是【更新库存】了，通过对更新库存的操作进行断点，我们查看库存的扣减情况，下面过程中发现当【更新库存 -> 释放锁】的步骤执行完，数据库中的数据并没有更新，事务并没有提交。


![image.png](/static/img/1f685f9722aeb005f2fad4621fd17c4e.image.webp)

上面场景中，上一次线程库存数量已更新为18个，但是当前线程读取到的还是19个，且对此库存进行扣减，初步分析为上一个事务没有提交，当前线程就已经读取库存了。

说到这，了解事务实现原理的童鞋可能已经分析出来了，**<span style='color:red'>事务底层是通过aop实现，aop底层又是动态代理对象实现</span>，此时上一个线程update方法执行结束，锁已经释放了，但是整个service方法还没有执行结束，后置处理中的事务还没有提交，其他线程此时开始加锁读取库存数量，就导致了此问题的产生**。


## 解决方式

解决方式就比较多了，根据不同业务复杂度，可做不同的处理

1、业务场景简单的情况，将锁直接提到上层，调用带事务的service即可

```java
    public void test3(){
        // 加锁
        ReentrantLock lock = new ReentrantLock();
        for (int i = 0; i < 30; i++) {
            new Thread(() -> {
                lock.lock();
                try {
                    customExecutorService.updateById(1L);
                }finally {
                    // 释放锁
                    lock.unlock();
                }
            }).start();
        }
    }
```

查看数据，发现正常扣减了


![image.png](/static/img/9962b4027812cdc7f34665cb0fb657cc.image.webp)

2、业务场景复杂的情况，要考虑锁的力度，根据业务逻辑拆分接口，可将逻辑校验都提到代码最前方，将库存校验留到校验的最后，且与更新库存进行绑定，进行加锁处理，流程如下

```java

    // 加锁 - 此处等同于分布式锁
    ReentrantLock lock = new ReentrantLock();
    
    @Override
    public void updateById(Long id) {
        try {
            // 其他逻辑处理...
            
            lock.lock();
            // 处理事务
            stockNum(id);
        }finally {
            // 释放锁
            lock.unlock();
        }
    }

    @SneakyThrows
    @Transactional
    void stockNum(Long id) {
        // 查询物料库存，扣减，然后更新库存
        MaterialStock materialStock = materialStockMapper.selectById(id);
        Long stockNum = materialStock.getStockNum();
        if (materialStock.getStockNum() <= 0) {
            log.info("库存不足");
            return;
        }
        materialStock.setStockNum(stockNum - 1);
        materialStockMapper.updateById(materialStock.getId(), materialStock.getStockNum());
        log.info("当前库存数量:{}\t，更新后库存数量:{}", stockNum, materialStock.getStockNum());

        // 其他IO处理，耗时 500ms
        TimeUnit.MILLISECONDS.sleep(500);
    }

```

## 总结

解决这个问题的本质，**就是不要将锁，放到被事务方法中**，同时也要思考如果是其他aop切面或者自定义代理了方法会不会有影响。

往往开发的过程中使用的技术体系与底层的实现原理息息相关，掌握原理带动大脑思考

基于 Spring 声明式事务下锁失效的场景分析

对于Java新手来说，日志查询是公司实际开发中必备技能，对于老手来说，怎么更快捷的查询日志定位问题才是关键。我整理了工作中日志查询常用的命令与技巧，以及一些生产日志定位问题的实战经验，欢迎各位小伙伴留言补充命令用法与场景描述。



# 日志查询

## 命令
使用的命令无非就是[tail](https://www.runoob.com/linux/linux-comm-tail.html)、
[cat](https://www.runoob.com/linux/linux-comm-cat.html)、[grep](https://www.runoob.com/linux/linux-comm-grep.html)、
[head](https://www.runoob.com/linux/linux-comm-head.html)、[sed](https://www.runoob.com/linux/linux-comm-sed.html)等，这些命令都是linux系统自带的，不需要安装。


## 玩法

在玩之前，先了解以上命令的基础用法，不然直接上手，也是一脸懵。

### 实时输出日志

```shell
# 实时输出日志
tail -f catalina.out

# 实时输出日志文件中所有模糊匹配到'Exception'的行
tail -f catalina.out | grep 'Exception'

# --line-buffered 是一行的缓冲区，只要这一行的缓冲区满了就会打印出来，添加此命令可用于实时监控日志
tail -f catalina.out | grep --line-buffered 'Exception'

# -200f 表示输出最后200行日志内出现过'Exception'的行，且继续实时输出出现过'Exception'的行
tail -200f catalina.out | grep 'Exception'
```

:::warning{title="警告"}
`tail -n +200 catalina.out` 从第200行开始输出日志，不会停止，需要手动停止<kbd>Ctrl</kbd>+<kbd>C</kbd>，除非紧跟grep搜索，要不然日志输出刹不住车啊
:::

### 非实时查询日志
```shell
# -n 200 表示输出最后200行出现'Exception'的行日志，不会实时输出日志
tail -n 200 catalina.out | grep 'Exception'

# 输出最后200行日志，且分页显示
tail -n 200 catalina.out | more 

# 从第200行开始输出日志
tail -n +200 catalina.out 

# 查询200行以后日志，并查找关键字'Exception'
tail -n +200 catalina.out | grep 'Exception'

# 显示全部日志信息，从头开始输出
cat catalina.out

# 查看日志文件中所有出现过'Exception'信息，-n是带行号输出
cat -n catalina.out | grep 'Exception'

# 查看日志中所有出现过'Exception'信息，-n是带行号输出，输出到文件Exception.txt
cat -n catalina.out | grep 'Exception' > Exception.txt

# 查询日志文件中所有出现过'Exception'信息，且显示前后100行（-A 查询之后的、-B 查询之前的、-C 查询前后的）
cat catalina.out | grep 'Exception' -C 100

# 查询200行以后的日志，且只显示10行，也就是查看200到210行之间的日志
cat -n catalina.out | tail -n +200 | head -n 10

# 查询5到10行日志
sed -n '5,10p' catalina.out

# 查询日志文件中的前200行日志(与 tail -n 正好相反)
head -n 200 catalina.out 

# 查询日志前200行，出现过'Exception'的行
head -n 200 catalina.out | grep 'Exception'

# 查看日志中出现过'Exception'的行数
grep 'Exception' catalina.out | wc -l

# 查询日志中出现123或者abc的行
grep -E '123|abc' catalina.out

# 查找当前目录下所有扩展名为.log的文件，并找出包含'Exception'的行
find . -name '*.log' | xargs grep 'Exception'

# 查询多个日志文件中出现过'Exception'的行
grep 'Exception' 2023-05-10.log 2023-05-09.log

```

:::warning{title="警告"}
`cat catalina.out` 查看文件会从头开始输出，不会停止，需要手动停止<kbd>Ctrl</kbd>+<kbd>C</kbd>，除非紧跟grep搜索，要不然日志输出刹不住车啊
:::

## 实战

### 查询某个'Exception'的行号，然后查询其行号往下10行的日志
```shell
# 查询所有出现过 'Exception' 的行号
cat -n catalina.out | grep 'Exception'

# 根据行号80021查询附近日志，且只显示10行
cat -n catalina.out | tail -n +80021 | head -n 10
```

### 查询时间范围内，某个线程的所有日志
```shell
# 首先要进行范围时间段内日志查询先查看是否在当前日之内存在，也就是说 11-07 18:29:20 必须在日志中存在这个时间点（如果日期时间已确认，可直接执行sed命令）
grep '11-07 18:29:20' catalina.out
grep '11-07 18:31:11' catalina.out

# 或者根据grep搜索到的日志确认日期行号（查询后确认日期真实存在，比如，确实存在 2023-04-10 17:39:03.883 的日志，可直接执行sed命令）
cat -n catalina.out | grep 717892

# 时间范围内的查询，以4-10 17:39:03.883为起点，到4-10 17:39:05所有毫秒的日志
sed -n '/4-10 17:39:03.883/,/4-10 17:39:05.*/p' catalina.out
 
 # 时间范围内的查询，以11-07 18:29分为起点，到11-07 18:31分之间的所有日志
sed -n '/11-07 18:29:/,/11-07 18:31:/p' catalina.out | grep 'http-nio-8084-exec-6'
```

日志快速查询的命令与技巧

baidu-site-verification

本人自己的博客，对工作与学习过程中的总结、一些场景设计的实现方案、遇到过的疑难问题与解决、以及面试总结等。