为什么把私钥写在代码里是一个致命错误

在技术社区经常能看到一些开发者分享的教训，前几天就有人发帖讲述一位Java开发者因同事将私钥直接硬编码在代码里而感到愤怒的事情。这种情况虽然听起来可笑，但在开发团队中却相当常见，尤其对于经验不足的程序员来说。

为什么把私钥写在代码里如此危险？

1. 代码会被分享和同步

代码通常会提交到Git或SVN等版本控制系统中。一旦私钥被提交，团队中的每个人都能看到这些敏感信息。即使后来删除了私钥，在历史记录中依然可以找到。有开发者就分享过真实案例：团队成员意外将AWS密钥提交到GitHub，结果第二天账单暴增数千元——有人利用泄露的密钥进行了挖矿活动。

2. 违反安全和职责分离原则

在规范的开发流程中，密钥管理和代码开发应该严格分离。通常由运维团队负责密钥管理，而开发人员则不需要（也不应该）直接接触生产环境的密钥。这是基本的安全实践。

3. 环境迁移的噩梦

当应用从开发环境迁移到测试环境，再到生产环境时，如果密钥硬编码在代码中，每次环境切换都需要修改代码并重新编译。这不仅效率低下，还容易出错。

正确的做法

业内已有多种成熟的解决方案：

• 使用环境变量存储敏感信息


• 采用专门的配置文件（确保加入.gitignore）


• 使用AWS KMS、HashiCorp Vault等专业密钥管理系统


• 在CI/CD流程中动态注入密钥

有开发团队就曾经花费两周时间清理代码中的硬编码密钥。其中甚至发现了一个已离职员工留下的"临时"数据库密码，注释中写着"临时用，下周改掉"——然而那个"下周"已经过去五年了。

作为专业开发者，应当始终保持良好的安全习惯。将私钥硬编码进代码，就像把家门钥匙贴在门上一样不可理喻。

这个教训值得所有软件工程师引以为戒。

提醒一下

双Token机制并没有从根本上解决安全性的问题，本文章只是提供一个思路，具体是否选择请大家仔细斟酌考虑，笔者水平有限，非常抱歉对你造成不好的体验。

token有效期设置问题

最近在做用户认证模块的后端功能开发，之前就有一个问题困扰了我好久，就是如何设置token的过期时间，前端在申请后端登录接口成功之后，会返回一个token值，存储在用户端本地，用户要访问后端的其他接口必须通过请求头带上这个token值，但是这个token的有效期应该设置为多少?

• 
  
  
  
  • 
    
    
    
    • 一旦token泄露，攻击者可长期冒充用户身份，直到token过期，服务端无法限制其访问用户数据
    
    
    • 虽然可以依赖黑名单机制，但会增加系统复杂度，还要进行系统监测
    
    
    • 如果在这段时间恶意用户利用未过期的条款持续调用后端API将会导致资源耗尽或产生巨额费用
    
    
    
    
  
  
  
  

所以有没有两者都兼顾的方案呢?

双token无感刷新方案

传统的token方案要么频繁要求用户重新登录，要么面临长期有效的安全风险

但是双token无感刷新机制，通过组合设计，在保证安全性的情况下，实现无感知的认证续期

核心设计

大致的执行流程如下

用户登录之后，后端返回access_token和refresh_token响应给前端，前端将两个token存储在用户本地

在用户端发起前端请求，访问后端接口，在请求头中携带上access_token

前端会对access_token的过期时间进行检测，当access_token过期前一分钟，前端通过refresh_token向后端发起请求，后端判断refresh_token是否有效，有效则重新获取新的access_token，返回给前端替换掉之前的access_token存储在用户本地，无效则要求用户重新认证

这样的话对于用户而言token的刷新是无感知的，不会影响用户体验，只有当refresh_token失效之后，才需要用户重新进行登录认证，同时，后端可以通过对用户refresh_token的管理来限制用户对后端接口的请求，大大提高了安全性

有了这个思路，写代码就简单了

@Service

public class LoginServiceImpl implements LoginService {



    @Autowired

    private JwtUtils jwtUtils;



    // token过期时间

    private static final Integer TOKEN_EXPIRE_DAYS =5;

    // token续期时间



    private static final Integer TOKEN_RENEWAL_MINUTE =15;



    @Override

    public boolean verify(String refresh_token) {

        Long uid = jwtUtils.getUidOrNull(refresh_token);

        if (Objects.isNull(uid)) {

            return false;

        }

        String key = RedisKey.getKey(RedisKey.USER_REFRESH_TOKEN,uid);

        String realToken = RedisUtils.getStr(key);

        return Objects.equals(refresh_token, realToken);

    }



    @Override

    public void renewalTokenIfNecessary(String refresh_token) {

        Long uid = jwtUtils.getUidOrNull(refresh_token);

        if (Objects.isNull(uid)) {

            return;

        }

        String refresh_key = RedisKey.getKey(RedisKey.USER_REFRESH_TOKEN, uid);

        long expireSeconds = RedisUtils.getExpire(refresh_key, TimeUnit.SECONDS);

        if (expireSeconds == -2) { // key不存在，refresh_token已过期

            return;

        }

        String access_key = RedisKey.getKey(RedisKey.USER_ACCESS_TOKEN, uid);

        RedisUtils.expire(access_key, TOKEN_RENEWAL_MINUTE, TimeUnit.MINUTES);

    }



    @Override

    @Transactional(rollbackFor = Exception.class)

    @RedissonLock(key = "#uid")

    public LoginTokenResponse login(Long uid) {

        String refresh_key = RedisKey.getKey(RedisKey.USER_REFRESH_TOKEN, uid);

        String access_key = RedisKey.getKey(RedisKey.USER_ACCESS_TOKEN, uid);

        String refresh_token = RedisUtils.getStr(refresh_key);

        String access_token;

        if (StrUtil.isNotBlank(refresh_token)) { //刷新令牌不为空

            access_token = jwtUtils.createToken(uid);

            RedisUtils.set(access_key, access_token, TOKEN_RENEWAL_MINUTE, TimeUnit.MINUTES);

            return LoginTokenResponse.builder()

                    .refresh_token(refresh_token).access_token(access_token)

                    .build();

        }

        refresh_token = jwtUtils.createToken(uid);

        RedisUtils.set(refresh_key, refresh_token, TOKEN_EXPIRE_DAYS, TimeUnit.DAYS);

        access_token = jwtUtils.createToken(uid);

        RedisUtils.set(access_key, access_token, TOKEN_RENEWAL_MINUTE, TimeUnit.MINUTES);

        return LoginTokenResponse.builder()

                .refresh_token(refresh_token).access_token(access_token)

                .build();

    }

}}

注意事项

安全问题

双Token机制并没有从根本上解决安全性的问题，它只是尝试通过改进设计，优化用户体验，全面的安全策略需要多层防护，分别针对不同类型的威胁和风险，而不仅仅依赖于Token的管理方式或数量

安全是一个持续对抗的过程，关键在于提高攻击者的成本，而非追求绝对防御。

"完美的认证方案不存在，但聪明的权衡永远存在。"

本笔者水平有限，望各位海涵

如果文章中有不对的地方，欢迎大家指正。

大家好呀，我是猿java。

在分布式系统中，我们经常听到灰度发布这个词，那么，什么是灰度发布？为什么需要灰度发布？如何实现灰度发布？这篇文章，我们来聊一聊。

1. 什么是灰度发布？

简单来说，灰度发布也叫做渐进式发布或金丝雀发布，它是一种逐步将新版本应用到生产环境中的策略。相比于一次性全量发布，灰度发布可以让我们在小范围内先行测试新功能，监控其表现，再决定是否全面推开。这样做的好处是显而易见的：

2. 原理解析

要理解灰度发布，我们需要先了解一下它的基本流程：

在这个过程中，关键在于如何切分流量，确保新旧版本平稳过渡。常见的切分方式包括：

• 基于用户ID：根据用户的唯一标识，将部分用户指向新版本。


• 基于地域：先在特定地区进行发布，观察效果后再扩展到其他地区。


• 基于设备：例如，先在Android或iOS用户中进行发布。

3. 示例演示

为了更好地理解灰度发布，接下来，我们通过一个简单的 Java示例来演示基本的灰度发布策略。假设我们有一个简单的 Web应用，有两个版本的登录接口/login/v1和/login/v2，我们希望将百分之十的流量引导到v2，其余流量继续使用v1。

3.1 第一步：引入灰度策略

我们可以通过拦截器（Interceptor）来实现流量的切分。以下是一个基于Spring Boot的简单实现：

import org.springframework.stereotype.Component;

import org.springframework.web.servlet.HandlerInterceptor;



import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.util.Random;



@Component

public class GrayReleaseInterceptor implements HandlerInterceptor {



    private static final double GRAY_RELEASE_PERCENT = 0.1; // 10% 流量



    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        String uri = request.getRequestURI();

        if ("/login".equals(uri)) {

            if (isGrayRelease()) {

                // 重定向到新版本接口

                response.sendRedirect("/login/v2");

                return false;

            } else {

                // 使用旧版本接口

                response.sendRedirect("/login/v1");

                return false;

            }

        }

        return true;

    }



    private boolean isGrayRelease() {

        Random random = new Random();

        return random.nextDouble() < GRAY_RELEASE_PERCENT;

    }

}

3.2 第二步：配置拦截器

在Spring Boot中，我们需要将拦截器注册到应用中：

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.context.annotation.Configuration;

import org.springframework.web.servlet.config.annotation.*;



@Configuration

public class WebConfig implements WebMvcConfigurer {



    @Autowired

    private GrayReleaseInterceptor grayReleaseInterceptor;



    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        registry.addInterceptor(grayReleaseInterceptor).addPathPatterns("/login");

    }

}

3.3 第三步：实现不同版本的登录接口

import org.springframework.web.bind.annotation.*;



@RestController

@RequestMapping("/login")

public class LoginController {



    @GetMapping("/v1")

    public String loginV1(@RequestParam String username, @RequestParam String password) {

        // 旧版本登录逻辑

        return "登录成功 - v1";

    }



    @GetMapping("/v2")

    public String loginV2(@RequestParam String username, @RequestParam String password) {

        // 新版本登录逻辑

        return "登录成功 - v2";

    }

}

在上面三个步骤之后，我们就实现了登录接口地灰度发布：

• 当用户访问/login时，拦截器会根据设定的灰度比例（10%）决定请求被重定向到/login/v1还是/login/v2。


• 大部分用户会体验旧版本接口，少部分用户会体验新版本接口。

3.4 灰度发布优化

上述示例，我们只是一个简化的灰度发布实现，实际生产环境中，我们可能需要更精细的灰度策略，例如：

4. 为什么需要灰度发布？

在实际工作中，为什么我们要使用灰度发布？这里我们总结了几个重要的原因。

4.1 降低发布风险

每次发布新版本，尤其是功能性更新或架构调整，都会伴随着一定的风险。即使经过了充分的测试，实际生产环境中仍可能出现意想不到的问题。灰度发布通过将新版本逐步推向部分用户，可以有效降低全量发布可能带来的风险。

举个例子，假设你上线了一个全新的支付功能，直接面向所有用户开放。如果这个功能存在严重 bug，可能导致大量用户无法完成支付，甚至影响公司声誉。而如果采用灰度发布，先让10%的用户体验新功能，发现问题后只需影响少部分用户，修复起来也更为迅速和容易。

4.2 快速回滚

在传统的全量发布中，一旦发现问题，回滚到旧版本可能需要耗费大量时间和精力，尤其是在高并发系统中，数据状态的同步与恢复更是复杂。而灰度发布由于新版本只覆盖部分流量，问题定位和回滚变得更加简单和快速。

比如说，你在灰度发布阶段发现新版本的某个功能在某些特定条件下会导致系统崩溃，立即可以停止向新用户推送这个版本，甚至只针对受影响的用户进行回滚操作，而不用影响全部用户的正常使用。

4.3 实时监控与反馈

灰度发布让你有机会在真实的生产环境中监控新版本的表现，并收集用户的反馈。这些数据对于评估新功能的实际效果至关重要，有助于做出更明智的决策。

举个具体的场景，你新增了一个推荐算法，希望提升用户的点击率。在灰度发布阶段，你可以监控新算法带来的点击率变化、服务器负载情况等指标，确保新算法确实带来了预期的效果，而不是引入了新的问题。

4.4 提升用户体验

通过灰度发布，你可以在推出新功能时，逐步优化用户体验。先让一部分用户体验新功能，收集他们的使用反馈，根据反馈不断改进，最终推出一个更成熟、更符合用户需求的版本。

举个例子，你开发了一项新的用户界面设计，直接全量发布可能会让一部分用户感到不适应或不满意。灰度发布允许你先让一部分用户体验新界面，收集他们的意见，进行必要的调整，再逐步扩大使用范围，确保最终发布的版本能获得更多用户的认可和喜爱。

4.5 支持A/B测试

灰度发布是实现A/B测试的基础。通过将用户随机分配到不同的版本，你可以比较不同版本的表现，选择最优方案进行全面推行。这对于优化产品功能和提升用户体验具有重要意义。

比如说，你想测试两个不同的推荐算法，看哪个能带来更高的转化率。通过灰度发布，将用户随机分配到使用算法A和算法B的版本，比较它们的表现，最终选择效果更好的算法进行全面部署。

4.6 应对复杂的业务需求

在一些复杂的业务场景中，全量发布可能无法满足灵活的需求，比如分阶段推出新功能、针对不同用户群体进行差异化体验等。灰度发布提供了更高的灵活性和可控性，能够更好地适应多变的业务需求。

例如，你正在开发一个面向企业用户的新功能，希望先让部分高价值客户试用，收集他们的反馈后再决定是否全面推广。灰度发布让这一过程变得更加顺畅和可控。

5. 总结

本文，我们详细地分析了灰度发布，它是一种强大而灵活的部署策略，能有效降低新版本上线带来的风险，提高系统的稳定性和用户体验。作为Java开发者，掌握灰度发布的原理和实现方法，不仅能提升我们的技术能力，还能为团队的项目成功保驾护航。

对于灰度发布，如果你有更多的问题或想法，欢迎随时交流！

6. 学习交流

如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。

URL 结尾是否带 / 主要影响的是 服务器如何解析请求 以及 相对路径的解析方式，具体区别如下：

1. 基础概念

• URL（统一资源定位符） ：用于唯一标识互联网资源，如网页、图片、API等。


• 目录 vs. 资源：
  
  
  
  
  • 以 / 结尾的 URL 通常表示目录，例如：
    
    

    https://example.com/folder/
    
    

    
    
  
  
  • 不以 / 结尾的 URL 通常指向具体的资源（如文件），例如：
    
    

    https://example.com/file
    
    

    
    
  
  
  
  

2. 带 / 和不带 / 的具体区别

（1）目录 vs. 资源

• https://example.com/folder/
  
  
  
  
  • 服务器通常会将其解析为 目录，并尝试返回该目录下的默认文件（如 index.html）。
  
  
  
  


• https://example.com/folder
  
  
  
  
  • 服务器可能会将其视为 文件，如果 folder 不是文件，而是目录，服务器可能会返回 301 重定向到 folder/。
  
  
  
  

📌 示例：

• 访问 https://example.com/blog/
  
  
  
  
  • 服务器可能返回 https://example.com/blog/index.html。
  
  
  
  


• 访问 https://example.com/blog（如果 blog 是个目录）
  
  
  
  
  • 服务器可能重定向到 https://example.com/blog/，再返回 index.html。
  
  
  
  

（2）相对路径解析

URL 末尾是否有 / 会影响相对路径的解析。

假设 HTML 页面包含以下 <img> 标签：

<img src="image.png">

📌 示例：

• 访问 https://example.com/folder/
  
  
  
  
  • 图片路径解析为 https://example.com/folder/image.png
  
  
  
  


• 访问 https://example.com/folder
  
  
  
  
  • 图片路径解析为 https://example.com/image.png
  
  
  • 可能导致 404 错误，因为 image.png 在 folder/ 里，而浏览器错误地去 example.com/ 下查找。
  
  
  
  

原因：

• 以 / 结尾的 URL，浏览器会认为它是一个目录，相对路径会基于 folder/ 解析。


• 不带 /，浏览器可能认为 folder 是文件，相对路径解析可能会出现错误。

（3）SEO 影响

搜索引擎对 https://example.com/folder/ 和 https://example.com/folder 可能会视为两个不同的页面，导致 重复内容问题，影响 SEO 排名。因此：

• 网站通常会选择 一种形式 并用 301 重定向 规范化 URL。


• 例如：
  
  
  
  
  • https://example.com/folder 自动跳转 到 https://example.com/folder/。
  
  
  • 反之亦然。
  
  
  
  

（4）API 请求

对于 RESTful API，带 / 和不带 / 可能导致不同的行为：

• https://api.example.com/users
  
  
  
  
  • 可能返回所有用户数据。
  
  
  
  


• https://api.example.com/users/
  
  
  
  
  • 可能返回 404 或者产生不同的结果（取决于服务器实现）。
  
  
  
  

一些 API 服务器对 / 非常敏感，因此最好遵循 API 文档的规范。

3. 总结

如果你在开发网站，建议：

在日常的软件开发工作中，存储时间是一项基础且常见的需求。无论是记录数据的操作时间、金融交易的发生时间，还是行程的出发时间、用户的下单时间等等，时间信息与我们的业务逻辑和系统功能紧密相关。因此，正确选择和使用 MySQL 的日期时间类型至关重要，其恰当与否甚至可能对业务的准确性和系统的稳定性产生显著影响。

本文旨在帮助开发者重新审视并深入理解 MySQL 中不同的时间存储方式，以便做出更合适项目业务场景的选择。

不要用字符串存储日期

和许多数据库初学者一样，笔者在早期学习阶段也曾尝试使用字符串（如 VARCHAR）类型来存储日期和时间，甚至一度认为这是一种简单直观的方法。毕竟，'YYYY-MM-DD HH:MM:SS' 这样的格式看起来清晰易懂。

但是，这是不正确的做法，主要会有下面两个问题：

DATETIME 和 TIMESTAMP 选择

DATETIME 和 TIMESTAMP 是 MySQL 中两种非常常用的、用于存储包含日期和时间信息的数据类型。它们都可以存储精确到秒（MySQL 5.6.4+ 支持更高精度的小数秒）的时间值。那么，在实际应用中，我们应该如何在这两者之间做出选择呢？

下面我们从几个关键维度对它们进行对比：

时区信息

DATETIME 类型存储的是字面量的日期和时间值，它本身不包含任何时区信息。当你插入一个 DATETIME 值时，MySQL 存储的就是你提供的那个确切的时间，不会进行任何时区转换。

这样就会有什么问题呢？ 如果你的应用需要支持多个时区，或者服务器、客户端的时区可能发生变化，那么使用 DATETIME 时，应用程序需要自行处理时区的转换和解释。如果处理不当（例如，假设所有存储的时间都属于同一个时区，但实际环境变化了），可能会导致时间显示或计算上的混乱。

TIMESTAMP 和时区有关。存储时，MySQL 会将当前会话时区下的时间值转换成 UTC（协调世界时）进行内部存储。当查询 TIMESTAMP 字段时，MySQL 又会将存储的 UTC 时间转换回当前会话所设置的时区来显示。

这意味着，对于同一条记录的 TIMESTAMP 字段，在不同的会话时区设置下查询，可能会看到不同的本地时间表示，但它们都对应着同一个绝对时间点（UTC 时间）。这对于需要全球化、多时区支持的应用来说非常有用。

下面实际演示一下！

建表 SQL 语句：

CREATE TABLE `time_zone_test` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,

  `date_time` datetime DEFAULT NULL,

  `time_stamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

插入一条数据（假设当前会话时区为系统默认，例如 UTC+0）:：

INSERT INTO time_zone_test(date_time,time_stamp) VALUES(NOW(),NOW());

查询数据（在同一时区会话下）：

SELECT date_time, time_stamp FROM time_zone_test;

结果：

+---------------------+---------------------+

| date_time           | time_stamp          |

+---------------------+---------------------+

| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 |

+---------------------+---------------------+

现在，修改当前会话的时区为东八区 (UTC+8):

SET time_zone = '+8:00';

再次查询数据：

# TIMESTAMP 的值自动转换为 UTC+8 时间

+---------------------+---------------------+

| date_time           | time_stamp          |

+---------------------+---------------------+

| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 |

+---------------------+---------------------+

扩展：MySQL 时区设置常用 SQL 命令

# 查看当前会话时区

SELECT @@session.time_zone;

# 设置当前会话时区

SET time_zone = 'Europe/Helsinki';

SET time_zone = "+00:00";

# 数据库全局时区设置

SELECT @@global.time_zone;

# 设置全局时区

SET GLOBAL time_zone = '+8:00';

SET GLOBAL time_zone = 'Europe/Helsinki';

占用空间

下图是 MySQL 日期类型所占的存储空间（官方文档传送门：dev.mysql.com/doc/refman/…）：

在 MySQL 5.6.4 之前，DateTime 和 TIMESTAMP 的存储空间是固定的，分别为 8 字节和 4 字节。但是从 MySQL 5.6.4 开始，它们的存储空间会根据毫秒精度的不同而变化，DateTime 的范围是 58 字节，TIMESTAMP 的范围是 47 字节。

表示范围

TIMESTAMP 表示的时间范围更小，只能到 2038 年：

• DATETIME：'1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'


• TIMESTAMP：'1970-01-01 00:00:01.000000' UTC 到 '2038-01-19 03:14:07.999999' UTC

性能

由于 TIMESTAMP 在存储和检索时需要进行 UTC 与当前会话时区的转换，这个过程可能涉及到额外的计算开销，尤其是在需要调用操作系统底层接口获取或处理时区信息时。虽然现代数据库和操作系统对此进行了优化，但在某些极端高并发或对延迟极其敏感的场景下，DATETIME 因其不涉及时区转换，处理逻辑相对更简单直接，可能会表现出微弱的性能优势。

为了获得可预测的行为并可能减少 TIMESTAMP 的转换开销，推荐的做法是在应用程序层面统一管理时区，或者在数据库连接/会话级别显式设置 time_zone 参数，而不是依赖服务器的默认或操作系统时区。

数值时间戳是更好的选择吗？

除了上述两种类型，实践中也常用整数类型（INT 或 BIGINT）来存储所谓的“Unix 时间戳”（即从 1970 年 1 月 1 日 00:00:00 UTC 起至目标时间的总秒数，或毫秒数）。

这种存储方式的具有 TIMESTAMP 类型的所具有一些优点，并且使用它的进行日期排序以及对比等操作的效率会更高，跨系统也很方便，毕竟只是存放的数值。缺点也很明显，就是数据的可读性太差了，你无法直观的看到具体时间。

时间戳的定义如下：

时间戳的定义是从一个基准时间开始算起，这个基准时间是「1970-1-1 00:00:00 +0:00」，从这个时间开始，用整数表示，以秒计时，随着时间的流逝这个时间整数不断增加。这样一来，我只需要一个数值，就可以完美地表示时间了，而且这个数值是一个绝对数值，即无论的身处地球的任何角落，这个表示时间的时间戳，都是一样的，生成的数值都是一样的，并且没有时区的概念，所以在系统的中时间的传输中，都不需要进行额外的转换了，只有在显示给用户的时候，才转换为字符串格式的本地时间。

数据库中实际操作：

-- 将日期时间字符串转换为 Unix 时间戳 (秒)

mysql> SELECT UNIX_TIMESTAMP('2020-01-11 09:53:32');

+---------------------------------------+

| UNIX_TIMESTAMP('2020-01-11 09:53:32') |

+---------------------------------------+

|                            1578707612 |

+---------------------------------------+

1 row in set (0.00 sec)



-- 将 Unix 时间戳 (秒) 转换为日期时间格式

mysql> SELECT FROM_UNIXTIME(1578707612);

+---------------------------+

| FROM_UNIXTIME(1578707612) |

+---------------------------+

| 2020-01-11 09:53:32       |

+---------------------------+

1 row in set (0.01 sec)

PostgreSQL 中没有 DATETIME

由于有读者提到 PostgreSQL（PG） 的时间类型，因此这里拓展补充一下。PG 官方文档对时间类型的描述地址：http://www.postgresql.org/docs/curren…。

可以看到，PG 没有名为 DATETIME 的类型：

• PG 的 TIMESTAMP WITHOUT TIME ZONE在功能上最接近 MySQL 的 DATETIME。它存储日期和时间，但不包含任何时区信息，存储的是字面值。


• PG 的TIMESTAMP WITH TIME ZONE (或 TIMESTAMPTZ) 相当于 MySQL 的 TIMESTAMP。它在存储时会将输入值转换为 UTC，并在检索时根据当前会话的时区进行转换显示。

对于绝大多数需要记录精确发生时间点的应用场景，TIMESTAMPTZ是 PostgreSQL 中最推荐、最健壮的选择，因为它能最好地处理时区复杂性。

总结

MySQL 中时间到底怎么存储才好？DATETIME?TIMESTAMP?还是数值时间戳？

并没有一个银弹，很多程序员会觉得数值型时间戳是真的好，效率又高还各种兼容，但是很多人又觉得它表现的不够直观。

《高性能 MySQL 》这本神书的作者就是推荐 TIMESTAMP，原因是数值表示时间不够直观。下面是原文：

每种方式都有各自的优势，根据实际场景选择最合适的才是王道。下面再对这三种方式做一个简单的对比，以供大家实际开发中选择正确的存放时间的数据类型：

选择建议小结：

• TIMESTAMP 的核心优势在于其内建的时区处理能力。数据库负责 UTC 存储和基于会话时区的自动转换，简化了需要处理多时区应用的开发。如果应用需要处理多时区，或者希望数据库能自动管理时区转换，TIMESTAMP 是自然的选择（注意其时间范围限制，也就是 2038 年问题）。


• 如果应用场景不涉及时区转换，或者希望应用程序完全控制时区逻辑，并且需要表示 2038 年之后的时间，DATETIME 是更稳妥的选择。


• 如果极度关注比较性能，或者需要频繁跨系统传递时间数据，并且可以接受可读性的牺牲（或总是在应用层转换），数值时间戳是一个强大的选项。

WebSocket 和 Socket 的区别

WebSocket 和 Socket 是两种不同的网络通信技术，它们在使用场景、协议、功能等方面有显著的差异。以下是它们之间的主要区别：

1. 定义

• Socket：Socket 是一种网络通信的工具，可以实现不同计算机之间的数据交换。它是操作系统提供的 API，广泛应用于 TCP/IP 网络编程中。Socket 可以是流式（TCP）或数据报（UDP）类型的，用于低层次的网络通信。


• WebSocket：WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。它允许服务器和客户端之间实时地交换数据。WebSocket 是建立在 HTTP 协议之上的，主要用于 Web 应用程序，以实现实时数据传输。

2. 协议层次

• Socket：Socket 是一种底层通信机制，通常与 TCP/IP 协议一起使用。它允许开发者通过编程语言直接访问网络接口。


• WebSocket：WebSocket 是一种应用层协议，建立在 HTTP 之上。在初始握手时，使用 HTTP 协议进行连接，之后切换到 WebSocket 协议进行数据传输。

3. 连接方式

• Socket：Socket 通常需要手动管理连接的建立和关闭。通过调用相关的 API，开发者需要处理连接的状态，确保数据的可靠传输。


• WebSocket：WebSocket 的连接管理相对简单。建立连接后，不需要频繁地进行握手，可以保持持久连接，随时进行数据交换。

4. 数据传输模式

• Socket：Socket 可以实现单向或双向的数据传输，但通常需要在发送和接收之间进行明确的控制。


• WebSocket：WebSocket 支持全双工通信，客户端和服务器之间可以随时互相发送数据，无需等待响应。这使得实时通信变得更加高效。

5. 适用场景

• Socket：Socket 常用于需要高性能、低延迟的场景，如游戏开发、文件传输、P2P 网络等。由于其底层特性，Socket 适合对网络性能有严格要求的应用。


• WebSocket：WebSocket 主要用于 Web 应用程序，如即时聊天、实时通知、在线游戏等。由于其易用性和高效性，WebSocket 特别适合需要实时更新和交互的前端应用。

6. 数据格式

• Socket：Socket 发送的数据通常是二进制流或文本流，需要开发者自行定义数据格式和解析方式。


• WebSocket：WebSocket 支持多种数据格式，包括文本（如 JSON）和二进制（如 Blob、ArrayBuffer）。WebSocket 的数据传输格式非常灵活，易于与 JavaScript 进行交互。

7. 性能

• Socket：Socket 对于大量并发连接的处理性能较高，但需要开发者进行优化和管理。


• WebSocket：WebSocket 在建立连接后可以保持长连接，减少了握手带来的延迟，适合高频率的数据交换场景。

8. 安全性

• Socket：Socket 的安全性取决于使用的协议（如 TCP、UDP）和应用层的实现。开发者需要自行处理安全问题，如加密和身份验证。


• WebSocket：WebSocket 支持通过 WSS（WebSocket Secure）进行加密，提供更高层次的安全保障。它可以很好地与 HTTPS 集成，确保数据在传输过程中的安全性。

9. 浏览器支持

• Socket：Socket 是底层的网络通信技术，通常不直接在浏览器中使用。Web 开发者需要通过后端语言（如 Node.js、Java、Python）来实现 Socket 通信。


• WebSocket：WebSocket 是专为 Web 应用设计的，所有现代浏览器均支持 WebSocket 协议，开发者可以直接在客户端使用 JavaScript API 进行通信。

10. 工具和库

• Socket：使用 Socket 进行开发时，开发者通常需要使用底层网络编程库，如 BSD Sockets、Java Sockets、Python's socket 模块等。


• WebSocket：WebSocket 提供了简单的 API，开发者可以使用原生 JavaScript 或第三方库（如 Socket.IO）轻松实现 WebSocket 通信。

结论

总结来说，WebSocket 是一种为现代 Web 应用量身定制的协议，具有实时、双向通信的优势，而 Socket 是一种底层的网络通信机制，提供更灵活的使用方式。选择使用哪种技术取决于具体的应用场景和需求。对于需要实时交互的 Web 应用，WebSocket 是更合适的选择；而对于底层或高性能要求的网络通信，Socket 提供了更多的控制和灵活性。

JSON是一种轻量级的数据交换格式，基于ECMAScript的一个子集设计，采用完全独立于编程语言的文本格式来表示数据。它易于人类阅读和编写，同时也便于机器解析和生成，这使得JSON在数据交换中具有高效性。‌

JSON也就成了每一个程序员每天都要使用一个小类库。无论你使用的谷歌的gson，阿里巴巴的fastjson，框架自带的jackjson，还是第三方的hutool的json等。总之，每天都要和他打交道。

但是，却在阴沟里翻了船。

1、平平无奇的接口

 /**

     * 获取vehicleinfo 信息

     *

     * @RequestParam vehicleId

     * @return Vehicle的json字符串

     */

    String loadVehicleInfo(Integer vehicleId);

该接口就是通过一个vehicleId参数获取Vehicle对象，返回的数据是Vehicle的JSON字符串，也就是将获取的对象信息序列化成JSON字符串了。

2、无懈可击的引用

String jsonStr = auctVehicleService.loadVehicleInfo(freezeDetail.getVehicle().getId());

if (StringUtils.isNotBlank(jsonStr)) {

    Vehicle vehicle = JSON.parseObject(jsonStr, Vehicle.class);

    if (vehicle != null) {

        // 后续省略 ... 

    }

}

看似无懈可击的引用，隐藏着魔鬼。为什么无懈可击，因为做了健壮性的判断，非空字符串、非空对象等的判断，根除了空指针异常。

但是，魔鬼隐藏在哪里呢？

3、故障引发

线上直接出现类似的故障（此报错信息为线下模拟）。

现在测试为什么没有问题：主要的测试了基础数据，测试的数据中恰好没有Date 类型的数据，所以线下没有测出来。

4、故障原因分析

从报错日志可以看出，是因为日期类型的参数导致的。Mar 24, 2025 1:23:10 PM 这样的日期格式无法使用Fastjson解析。

深入代码查看：

@Override

public String loadVehicleInfo(Integer vehicleId) {

    String key = VEHICLE_KEY + vehicleId;

    Object obj = cacheService.get(key);



    if (null != obj && StringUtils.isNotEmpty(obj.toString())

            && !"null".equals(obj.toString())) {

        String result = (String)obj;

        return result;

    }



    String json = null;

    try {

        Vehicle vInfo = overrideVehicleAttributes(vehicleId);

        // 使用了Gson序列化对象

        json = gson.toJson(vInfo);

        cacheService.setExpireSec(key, gson.toJson(vInfo), 5 * 60);

    } catch (Exception e) {

        cacheService.setExpireSec(key, "", 1 * 60);

    } finally {

    }



    return json;

}

原来接口的实现里面采用了谷歌的Gson对返回的对象做了序列化。调用的地方又使用了阿里巴巴的Fastjson发序列化，导致参数解析异常。

完蛋，上榜是要被扣工资的！！！

5、小结

问题虽小，但是影响却很大。坊间一直讨论着，程序员为什么不能写出没有bug的程序。这也许是其中的一种答案吧。

肉疼，被扣钱了！！！

--END--

喜欢就点赞收藏，也可以关注我的微信公众号：编程朝花夕拾

真快啊！Java 24 这两天已经正式发布啦！这是自 Java 21 以来的第三个非长期支持版本，和 Java 22、Java 23一样。

下一个长期支持版是 Java 25，预计今年 9 月份发布。

Java 24 带来的新特性还是蛮多的，一共 24 个。Java 23 和 Java 23 都只有 12 个，Java 24的新特性相当于这两次的总和了。因此，这个版本还是非常有必要了解一下的。

下图是从 JDK8 到 JDK 24 每个版本的更新带来的新特性数量和更新时间：

我在昨天晚上详细看了一下 Java 24 的详细更新，并对其中比较重要的新特性做了详细的解读，希望对你有帮助！

本文内容概览：

JEP 478: 密钥派生函数 API（预览）

密钥派生函数 API 是一种用于从初始密钥和其他数据派生额外密钥的加密算法。它的核心作用是为不同的加密目的（如加密、认证等）生成多个不同的密钥，避免密钥重复使用带来的安全隐患。 这在现代加密中是一个重要的里程碑，为后续新兴的量子计算环境打下了基础

通过该 API，开发者可以使用最新的密钥派生算法（如 HKDF 和未来的 Argon2）：

// 创建一个 KDF 对象，使用 HKDF-SHA256 算法

KDF hkdf = KDF.getInstance("HKDF-SHA256"); 



// 创建 Extract 和 Expand 参数规范

AlgorithmParameterSpec params =

    HKDFParameterSpec.ofExtract()

                     .addIKM(initialKeyMaterial) // 设置初始密钥材料

                     .addSalt(salt)             // 设置盐值

                     .thenExpand(info, 32);     // 设置扩展信息和目标长度



// 派生一个 32 字节的 AES 密钥

SecretKey key = hkdf.deriveKey("AES", params);



// 可以使用相同的 KDF 对象进行其他密钥派生操作

JEP 483: 提前类加载和链接

在传统 JVM 中，应用在每次启动时需要动态加载和链接类。这种机制对启动时间敏感的应用（如微服务或无服务器函数）带来了显著的性能瓶颈。该特性通过缓存已加载和链接的类，显著减少了重复工作的开销，显著减少 Java 应用程序的启动时间。测试表明，对大型应用（如基于 Spring 的服务器应用），启动时间可减少 40% 以上。

这个优化是零侵入性的，对应用程序、库或框架的代码无需任何更改，启动也方式保持一致，仅需添加相关 JVM 参数（如 -XX:+ClassDataSharing）。

JEP 484: 类文件 API

类文件 API 在 JDK 22 进行了第一次预览（JEP 457），在 JDK 23 进行了第二次预览并进一步完善（JEP 466）。最终，该特性在 JDK 24 中顺利转正。

类文件 API 的目标是提供一套标准化的 API，用于解析、生成和转换 Java 类文件，取代过去对第三方库（如 ASM）在类文件处理上的依赖。

// 创建一个 ClassFile 对象，这是操作类文件的入口。

ClassFile cf = ClassFile.of();

// 解析字节数组为 ClassModel

ClassModel classModel = cf.parse(bytes);



// 构建新的类文件，移除以 "debug" 开头的所有方法

byte[] newBytes = cf.build(classModel.thisClass().asSymbol(),

        classBuilder -> {

            // 遍历所有类元素

            for (ClassElement ce : classModel) {

                // 判断是否为方法 且 方法名以 "debug" 开头

                if (!(ce instanceof MethodModel mm

                        && mm.methodName().stringValue().startsWith("debug"))) {

                    // 添加到新的类文件中

                    classBuilder.with(ce);

                }

            }

        });

JEP 485: 流收集器

流收集器 Stream::gather(Gatherer) 是一个强大的新特性，它允许开发者定义自定义的中间操作，从而实现更复杂、更灵活的数据转换。Gatherer 接口是该特性的核心，它定义了如何从流中收集元素，维护中间状态，并在处理过程中生成结果。

与现有的 filter、map 或 distinct 等内置操作不同，Stream::gather 使得开发者能够实现那些难以用标准 Stream 操作完成的任务。例如，可以使用 Stream::gather 实现滑动窗口、自定义规则的去重、或者更复杂的状态转换和聚合。 这种灵活性极大地扩展了 Stream API 的应用范围，使开发者能够应对更复杂的数据处理场景。

基于 Stream::gather(Gatherer) 实现字符串长度的去重逻辑：

var result = Stream.of("foo", "bar", "baz", "quux")

                   .gather(Gatherer.ofSequential(

                       HashSet::new, // 初始化状态为 HashSet,用于保存已经遇到过的字符串长度

                       (set, str, downstream) -> {

                           if (set.add(str.length())) {

                               return downstream.push(str);

                           }

                           return true; // 继续处理流

                       }

                   ))

                   .toList();// 转换为列表



// 输出结果 ==> [foo, quux]

JEP 486: 永久禁用安全管理器

JDK 24 不再允许启用 Security Manager，即使通过 java -Djava.security.manager命令也无法启用，这是逐步移除该功能的关键一步。虽然 Security Manager 曾经是 Java 中限制代码权限（如访问文件系统或网络、读取或写入敏感文件、执行系统命令）的重要工具，但由于复杂性高、使用率低且维护成本大，Java 社区决定最终移除它。

JEP 487: 作用域值 （第四次预览）

作用域值（Scoped Values）可以在线程内和线程间共享不可变的数据，优于线程局部变量，尤其是在使用大量虚拟线程时。

final static ScopedValue<...> V = new ScopedValue<>();



// In some method

ScopedValue.where(V, <value>)

           .run(() -> { ... V.get() ... call methods ... });



// In a method called directly or indirectly from the lambda expression

... V.get() ...

作用域值允许在大型程序中的组件之间安全有效地共享数据，而无需求助于方法参数。

JEP 491: 虚拟线程的同步而不固定平台线程

优化了虚拟线程与 synchronized 的工作机制。 虚拟线程在 synchronized 方法和代码块中阻塞时，通常能够释放其占用的操作系统线程（平台线程），避免了对平台线程的长时间占用，从而提升应用程序的并发能力。 这种机制避免了“固定 (Pinning)”——即虚拟线程长时间占用平台线程，阻止其服务于其他虚拟线程的情况。

现有的使用 synchronized 的 Java 代码无需修改即可受益于虚拟线程的扩展能力。 例如，一个 I/O 密集型的应用程序，如果使用传统的平台线程，可能会因为线程阻塞而导致并发能力下降。 而使用虚拟线程，即使在 synchronized 块中发生阻塞，也不会固定平台线程，从而允许平台线程继续服务于其他虚拟线程，提高整体的并发性能。

JEP 493：在没有 JMOD 文件的情况下链接运行时镜像

默认情况下，JDK 同时包含运行时镜像（运行时所需的模块）和 JMOD 文件。这个特性使得 jlink 工具无需使用 JDK 的 JMOD 文件就可以创建自定义运行时镜像，减少了 JDK 的安装体积（约 25%）。

说明：

• Jlink 是随 Java 9 一起发布的新命令行工具。它允许开发人员为基于模块的 Java 应用程序创建自己的轻量级、定制的 JRE。


• JMOD 文件是 Java 模块的描述文件，包含了模块的元数据和资源。

JEP 495: 简化的源文件和实例主方法（第四次预览）

这个特性主要简化了 main 方法的的声明。对于 Java 初学者来说，这个 main 方法的声明引入了太多的 Java 语法概念，不利于初学者快速上手。

没有使用该特性之前定义一个 main 方法：

public class HelloWorld {

    public static void main(String[] args) {

        System.out.println("Hello, World!");

    }

}

使用该新特性之后定义一个 main 方法：

class HelloWorld {

    void main() {

        System.out.println("Hello, World!");

    }

}

进一步简化（未命名的类允许我们省略类名）

void main() {

   System.out.println("Hello, World!");

}

JEP 497: 量子抗性数字签名算法 (ML-DSA)

JDK 24 引入了支持实施抗量子的基于模块晶格的数字签名算法 （Module-Lattice-Based Digital Signature Algorithm, ML-DSA），为抵御未来量子计算机可能带来的威胁做准备。

ML-DSA 是美国国家标准与技术研究院（NIST）在 FIPS 204 中标准化的量子抗性算法，用于数字签名和身份验证。

JEP 498: 使用 sun.misc.Unsafe 内存访问方法时发出警告

JDK 23(JEP 471) 提议弃用 sun.misc.Unsafe 中的内存访问方法，这些方法将来的版本中会被移除。在 JDK 24 中，当首次调用 sun.misc.Unsafe 的任何内存访问方法时，运行时会发出警告。

这些不安全的方法已有安全高效的替代方案：

• java.lang.invoke.VarHandle ：JDK 9 (JEP 193) 中引入，提供了一种安全有效地操作堆内存的方法，包括对象的字段、类的静态字段以及数组元素。


• java.lang.foreign.MemorySegment ：JDK 22 (JEP 454) 中引入，提供了一种安全有效地访问堆外内存的方法，有时会与 VarHandle 协同工作。

这两个类是 Foreign Function & Memory API（外部函数和内存 API） 的核心组件，分别用于管理和操作堆外内存。Foreign Function & Memory API 在 JDK 22 中正式转正，成为标准特性。

import jdk.incubator.foreign.*;

import java.lang.invoke.VarHandle;



// 管理堆外整数数组的类

class OffHeapIntBuffer {



    // 用于访问整数元素的VarHandle

    private static final VarHandle ELEM_VH = ValueLayout.JAVA_INT.arrayElementVarHandle();



    // 内存管理器

    private final Arena arena;



    // 堆外内存段

    private final MemorySegment buffer;



    // 构造函数，分配指定数量的整数空间

    public OffHeapIntBuffer(long size) {

        this.arena  = Arena.ofShared();

        this.buffer = arena.allocate(ValueLayout.JAVA_INT, size);

    }



    // 释放内存

    public void deallocate() {

        arena.close();

    }



    // 以volatile方式设置指定索引的值

    public void setVolatile(long index, int value) {

        ELEM_VH.setVolatile(buffer, 0L, index, value);

    }



    // 初始化指定范围的元素为0

    public void initialize(long start, long n) {

        buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,

                       ValueLayout.JAVA_INT.byteSize() * n)

              .fill((byte) 0);

    }



    // 将指定范围的元素复制到新数组

    public int[] copyToNewArray(long start, int n) {

        return buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,

                              ValueLayout.JAVA_INT.byteSize() * n)

                     .toArray(ValueLayout.JAVA_INT);

    }

}

JEP 499: 结构化并发（第四次预览）

JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代java.util.concurrent，目前处于孵化器阶段。

结构化并发将不同线程中运行的多个任务视为单个工作单元，从而简化错误处理、提高可靠性并增强可观察性。也就是说，结构化并发保留了单线程代码的可读性、可维护性和可观察性。

结构化并发的基本 API 是StructuredTaskScope，它支持将任务拆分为多个并发子任务，在它们自己的线程中执行，并且子任务必须在主任务继续之前完成。

StructuredTaskScope 的基本用法如下：

    try (var scope = new StructuredTaskScope<Object>()) {

        // 使用fork方法派生线程来执行子任务

        Future<Integer> future1 = scope.fork(task1);

        Future<String> future2 = scope.fork(task2);

        // 等待线程完成

        scope.join();

        // 结果的处理可能包括处理或重新抛出异常

        ... process results/exceptions ...

    } // close

结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。

Java 新特性系列解读

如果你想系统了解 Java 8 以及之后版本的新特性，可以在 JavaGuide 上阅读对应的文章：

比较推荐这几篇：

• Java 11 新特性概览


• Java 17 新特性概览（重要）


• Java 21 新特性概览(重要)

在 MySQL 中，使用 UUID 作为主键 在大表中可能会导致性能问题，尤其是在插入和修改数据时效率较低。以下是详细的原因分析，以及为什么修改数据会导致索引刷新，以及字符主键为什么效率较低。

1. UUID 作为主键的问题

（1）UUID 的特性

• UUID 是一个 128 位的字符串，通常表示为 36 个字符（例如：550e8400-e29b-41d4-a716-446655440000）。


• UUID 是全局唯一的，适合分布式系统中生成唯一标识。

（2）UUID 作为主键的缺点

1. 索引效率低

• 索引大小：UUID 是字符串类型，占用空间较大（36 字节），而整型主键（如 BIGINT）仅占用 8 字节。索引越大，存储和查询的效率越低。


• 索引分裂：UUID 是无序的，插入新数据时，可能会导致索引树频繁分裂和重新平衡，影响性能。

2. 插入性能差

• 随机性：UUID 是无序的，每次插入新数据时，新记录可能会插入到索引树的任意位置，导致索引树频繁调整。


• 页分裂：InnoDB 存储引擎使用 B+ 树作为索引结构，随机插入会导致页分裂，增加磁盘 I/O 操作。

3. 查询性能差

• 比较效率低：字符串比较比整型比较慢，尤其是在大表中，查询性能会显著下降。


• 索引扫描范围大：UUID 索引占用的空间大，导致索引扫描的范围更大，查询效率降低。

2. 修改数据导致索引刷新的原因

（1）索引的作用

• 索引是为了加速查询而创建的数据结构（如 B+ 树）。


• 当数据被修改时，索引也需要同步更新，以保持数据的一致性。

（2）修改数据对索引的影响

• 更新主键：
  
  
  
  
  • 如果修改了主键值，MySQL 需要删除旧的主键索引记录，并插入新的主键索引记录。
  
  
  • 这个过程会导致索引树的调整，增加磁盘 I/O 操作。
  
  
  
  


• 更新非主键列：
  
  
  
  
  • 如果修改的列是索引列（如唯一索引、普通索引），MySQL 需要更新对应的索引记录。
  
  
  • 这个过程也会导致索引树的调整。
  
  
  
  

（3）UUID 主键的额外开销

• 由于 UUID 是无序的，修改主键值时，新值可能会插入到索引树的不同位置，导致索引树频繁调整。


• 相比于有序的主键（如自增 ID），UUID 主键的修改操作代价更高。

3. 字符主键导致效率降低的原因

（1）存储空间大

• 字符主键（如 UUID）占用的存储空间比整型主键大。


• 索引的大小直接影响查询性能，索引越大，查询时需要的磁盘 I/O 操作越多。

（2）比较效率低

• 字符串比较比整型比较慢，尤其是在大表中，查询性能会显著下降。


• 例如，WHERE id = '550e8400-e29b-41d4-a716-446655440000' 的效率低于 WHERE id = 12345。

（3）索引分裂

• 字符主键通常是无序的，插入新数据时，可能会导致索引树频繁分裂和重新平衡，影响性能。

4. 如何优化 UUID 主键的性能

（1）使用有序 UUID

• 使用有序 UUID（如 UUIDv7），减少索引分裂和页分裂。


• 有序 UUID 的生成方式可以基于时间戳，保证插入顺序。

（2）将 UUID 存储为二进制

• 将 UUID 存储为 BINARY(16) 而不是 CHAR(36)，减少存储空间。
  
  

  CREATE TABLE users (
  
      id BINARY(16) PRIMARY KEY,
  
      name VARCHAR(255)
  
  );
  
  

  
  

（3）使用自增主键 + UUID

• 使用自增主键作为物理主键，UUID 作为逻辑主键。
  
  

  CREATE TABLE users (
  
      id BIGINT AUTO_INCREMENT PRIMARY KEY,
  
      uuid CHAR(36) UNIQUE,
  
      name VARCHAR(255)
  
  );
  
  

  
  

（4）分区表

• 对大表进行分区，减少单个索引树的大小，提高查询性能。

~Summary

• UUID 作为主键的缺点：
  
  
  
  
  • 索引效率低，插入和查询性能差。
  
  
  • 修改数据时，索引需要频繁刷新，导致性能下降。
  
  
  
  


• 字符主键效率低的原因：
  
  
  
  
  • 存储空间大，比较效率低，索引分裂频繁。
  
  
  
  


• 优化建议：
  
  
  
  
  • 使用有序 UUID 或二进制存储。
  
  
  • 结合自增主键和 UUID。
  
  
  • 对大表进行分区。
  
  
  
  

如何限制一个账号只能在一处登录

要实现账号单点登录（一处登录限制），需结合 会话管理、实时状态同步 和 冲突处理机制。以下是完整技术方案：

一、核心实现方案

1. 服务端会话控制（推荐）

// 用户登录时生成唯一令牌并记录

public String login(String username, String password) {

    // 1. 验证账号密码

    User user = userService.authenticate(username, password);

  

    // 2. 生成新令牌并失效旧会话

    String newToken = UUID.randomUUID().toString();

    redis.del("user:" + user.getId() + ":token"); // 清除旧token

    redis.setex("user:" + user.getId() + ":token", 3600, newToken);

  

    // 3. 返回新令牌

    return newToken;

}

2. WebSocket实时踢出（增强体验）

// 前端建立长连接

const socket = new WebSocket(`wss://api.example.com/ws?token=${token}`);



socket.onmessage = (event) => {

    if (event.data === 'force_logout') {

        alert('您的账号在其他设备登录');

        location.href = '/logout';

    }

};

3. 登录设备指纹识别

// 生成设备指纹（前端）

function generateDeviceFingerprint() {

    const canvas = document.createElement('canvas');

    const ctx = canvas.getContext('2d');

    ctx.textBaseline = 'top';

    ctx.font = "14px Arial";

    ctx.fillText("BrowserFingerprint", 2, 2);

    return canvas.toDataURL().hashCode(); // 简化示例

}



// 服务端校验

if (storedFingerprint != currentFingerprint) {

    forceLogout(storedToken);

}

二、多端适配策略

客户端类型	实现方案
Web浏览器	JWT令牌 + Redis黑名单
移动端APP	设备ID绑定 + FCM/iMessage推送踢出
桌面应用	硬件指纹 + 本地令牌失效检测
微信小程序	UnionID绑定 + 服务端订阅消息

三、关键代码实现

1. JWT令牌增强方案

// 生成带设备信息的JWT

public String generateToken(User user, String deviceId) {

    return Jwts.builder()

        .setSubject(user.getId())

        .claim("device", deviceId) // 绑定设备

        .setExpiration(new Date(System.currentTimeMillis() + 3600000))

        .signWith(SignatureAlgorithm.HS512, secret)

        .compact();

}



// 校验令牌时检查设备

public boolean validateToken(String token, String currentDevice) {

    Claims claims = Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody();

    return claims.get("device").equals(currentDevice);

}

2. Redis实时状态管理

# 使用Redis Hash存储登录状态

def login(user_id, token, device_info):

    # 删除该用户所有活跃会话

    r.delete(f"user_sessions:{user_id}")

  

    # 记录新会话

    r.hset(f"user_sessions:{user_id}", 

           mapping={

               "token": token,

               "device": device_info,

               "last_active": datetime.now()

           })

    r.expire(f"user_sessions:{user_id}", 3600)



# 中间件校验

def check_token(request):

    user_id = get_user_id_from_token(request.token)

    stored_token = r.hget(f"user_sessions:{user_id}", "token")

    if stored_token != request.token:

        raise ForceLogoutError()

四、异常处理机制

场景	处理方案
网络延迟冲突	采用CAS（Compare-And-Swap）原子操作更新令牌
令牌被盗用	触发二次验证（短信/邮箱验证码）
多设备同时登录	后登录者优先，前会话立即失效（可配置为保留第一个登录）

五、性能与安全优化

1. 会话同步优化：

   # Redis Pub/Sub 跨节点同步
   
   PUBLISH user:123 "LOGOUT"
   
   

2. 安全增强：

   // 前端敏感操作二次确认
   
   function sensitiveOperation() {
   
       if (loginTime < lastServerCheckTime) {
   
           showReauthModal();
   
       }
   
   }
   
   

3. 监控看板：

   指标	报警阈值
   并发登录冲突率	>5%/分钟
   强制踢出成功率	<99%

六、行业实践参考

1. 金融级方案：
   • 每次操作都验证设备指纹
   • 异地登录需视频人工审核
2. 社交应用方案：
   • 允许最多3个设备在线
   • 分设备类型控制（手机+PC+平板）
3. ERP系统方案：
   • 绑定特定MAC地址
   • VPN网络白名单限制

通过以上方案可实现：

• 严格模式：后登录者踢出前会话（适合银行系统）
• 宽松模式：多设备在线但通知告警（适合社交应用）
• 混合模式：关键操作时强制单设备（适合电商系统）

部署建议：

1. 根据业务需求选择合适严格度
2. 关键系统增加异地登录二次验证
3. 用户界面明确显示登录设备列表

作者：Epicurus
来源：juejin.cn/post/7485384798569250868

Spring生态重大升级全景图

一、Spring 6.0核心特性详解

1. Java版本基线升级

• 最低JDK 17：全面拥抱Java模块化特性，优化现代JVM性能


• 虚拟线程（Loom项目）：轻量级线程支持高并发场景（需JDK 19+）

// 示例：虚拟线程使用

Thread.ofVirtual().name("my-virtual-thread").start(() -> {

    // 业务逻辑

});

• 
  
  
  
  1. 虚拟线程（Project Loom）
  
  
  
  


• 应用场景：电商秒杀系统、实时聊天服务等高并发场景

// 传统线程池 vs 虚拟线程

// 旧方案（平台线程）

ExecutorService executor = Executors.newFixedThreadPool(200);

// 新方案（虚拟线程）

ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor();

// 处理10000个并发请求

IntStream.range(0, 10000).forEach(i -> 

    virtualExecutor.submit(() -> {

        // 处理订单逻辑

        processOrder(i);

    })

);

2. HTTP接口声明式客户端

• @HttpExchange注解：类似Feign的声明式REST调用

@HttpExchange(url = "/api/users")

public interface UserClient {

    @GetExchange

    List<User> listUsers();

}

应用场景：微服务间API调用

@HttpExchange(url = "/products", accept = "application/json")

public interface ProductServiceClient {

    @GetExchange("/{id}")

    Product getProduct(@PathVariable String id);

    @PostExchange

    Product createProduct(@RequestBody Product product);

}

// 自动注入使用

@Service

public class OrderService {

    @Autowired

    private ProductServiceClient productClient;

    

    public void validateProduct(String productId) {

        Product product = productClient.getProduct(productId);

        // 校验逻辑...

    }

}

3. ProblemDetail异常处理

• RFC 7807标准：标准化错误响应格式

{

  "type": "https://example.com/errors/insufficient-funds",

  "title": "余额不足",

  "status": 400,

  "detail": "当前账户余额为50元，需支付100元"

}

• 应用场景：统一API错误响应格式

@RestControllerAdvice

public class GlobalExceptionHandler {

    @ExceptionHandler(ProductNotFoundException.class)

    public ProblemDetail handleProductNotFound(ProductNotFoundException ex) {

        ProblemDetail problem = ProblemDetail.forStatus(HttpStatus.NOT_FOUND);

        problem.setType(URI.create("/errors/product-not-found"));

        problem.setTitle("商品不存在");

        problem.setDetail("商品ID: " + ex.getProductId());

        return problem;

    }

}

// 触发异常示例

@GetMapping("/products/{id}")

public Product getProduct(@PathVariable String id) {

    return productRepo.findById(id)

           .orElseThrow(() -> new ProductNotFoundException(id));

}

4. GraalVM原生镜像支持

• AOT编译优化：启动时间缩短至毫秒级，内存占用降低50%+


• 编译命令示例：

native-image -jar myapp.jar

二、Spring Boot 3.0突破性改进

1. 基础架构升级

• Jakarta EE 9+：包名javax→jakarta全量替换


• 自动配置优化：更智能的条件装配策略


• 
  
  
  
  1. OAuth2授权服务器
     应用场景：构建企业级认证中心
  
  
  
  

# application.yml配置

spring:

  security:

    oauth2:

      authorization-server:

        issuer-url: https://auth.yourcompany.com

        token:

          access-token-time-to-live: 1h

定义权限端点

@Configuration

@EnableWebSecurity

public class AuthServerConfig {

    @Bean

    public SecurityFilterChain authServerFilterChain(HttpSecurity http) throws Exception {

        http

            .authorizeRequests(authorize -> authorize

                .anyRequest().authenticated()

            )

            .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt);

        return http.build();

    }

}

2. GraalVM原生镜像支持

应用场景：云原生Serverless函数

# 打包命令（需安装GraalVM）

mvn clean package -Pnative

# 运行效果对比

传统JAR启动：启动时间2.3s | 内存占用480MB

原生镜像启动：启动时间0.05s | 内存占用85MB

3. 增强监控（Prometheus集成）

• Micrometer 1.10+：支持OpenTelemetry标准


• 全新/actuator/prometheus端点：原生Prometheus格式指标


• 应用场景：微服务健康监测

// 自定义业务指标

@RestController

public class OrderController {

    private final Counter orderCounter = Metrics.counter("orders.total");

    @PostMapping("/orders")

    public Order createOrder() {

        orderCounter.increment();

        // 创建订单逻辑...

    }

}

# Prometheus监控指标示例

orders_total{application="order-service"} 42

http_server_requests_seconds_count{uri="/orders"} 15

三、升级实施路线图

四、新特性组合实战案例

场景：电商平台升级

// 商品查询服务（组合使用新特性）

@RestController

public class ProductController {

    // 声明式调用库存服务

    @Autowired

    private StockServiceClient stockClient;

    // 虚拟线程处理高并发查询

    @GetMapping("/products/{id}")

    public ProductDetail getProduct(@PathVariable String id) {

        return CompletableFuture.supplyAsync(() -> {

            Product product = productRepository.findById(id)

                             .orElseThrow(() -> new ProductNotFoundException(id));

            

            // 并行查询库存

            Integer stock = stockClient.getStock(id);

            return new ProductDetail(product, stock);

        }, Executors.newVirtualThreadPerTaskExecutor()).join();

    }

}

四、升级实践建议

通过以上升级方案：

本次升级标志着Spring生态正式进入云原生时代。重点关注：虚拟线程的资源管理策略、GraalVM的反射配置优化、OAuth2授权服务器的定制扩展等深度实践方向。

让闲置 Ubuntu 服务器华丽转身为家庭影院

在数字化的时代，家里的设备更新换代频繁，很容易就会有闲置的服务器吃灰。我家里就有一台闲置的 Ubuntu 24.04 服务器，一直放在角落，总觉得有些浪费。于是，我决定让它重新发挥作用，打造一个属于自己的家庭影院。

一、实现 Windows 与 Ubuntu 服务器文件互通

要打造家庭影院，首先得让本地 Windows 电脑和 Ubuntu 服务器之间能够方便地传输电影文件。我选择安装 Samba 来实现这一目的。

1. 安装 Samba：在 Ubuntu 服务器的终端中输入命令

   sudo apt-get install samba samba-common
   
   

   系统会自动下载并安装 Samba 相关的软件包。

2. 备份配置文件：为了以防万一，我先将原来的 Samba 配置文件进行备份，执行命令

   mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
   
   

3. 新建配置文件：使用 vim /etc/samba/smb.conf 命令打开编辑器，写入以下配置内容：

[global]

server min protocol = CORE

workgroup = WORKGR0UP

netbios name = Nas

security = user

map to guest = bad user

guest account = nobody

client min protocol = SMB2

server min protocol = SMB2

server smb encrypt = off

[NAS]

comment = NASserver

path = /home/bddxg/nas

public = Yes

browseable = Yes

writable = Yes

guest ok = Yes

passdb backend = tdbsam

create mask = 0775

directory mask = 0775

这里需要注意的是，我计划的媒体库目录是个人目录下的 nas/，所以 path 是 /home/bddxg/nas ，如果大家要部署的话记得根据自己的实际情况修改为对应的位置。 

4. 连接 Windows 电脑：在 Windows 电脑这边基本不需要什么复杂配置，因为在网络里无法直接看到 Ubuntu，我直接在电脑上添加了网络位置。假设服务器地址是 192.168.10.100，那么添加网络位置就是 \\192.168.10.100\nas，这样就可以在 Windows 电脑和 Ubuntu 服务器之间传输文件了。

二、安装 Jellyfin 搭建家庭影院

文件传输的问题解决后，接下来就是安装 Jellyfin 来实现家庭影院的功能了。

1. 尝试 Docker 安装失败：一开始我选择使用 Docker 安装，毕竟 Docker 有很多优点，使用起来也比较方便。按照官网指南进行操作，在第三步启动 Docker 并挂载本地目录的时候却一直失败。报错信息为:

   docker: Error response from daemon: error while creating mount source path '/srv/jellyfin/cache': mkdir /srv/jellyfin: read-only file system.
   
   

   即使我给 /srv/jellyfin 赋予了 777 权限也没有效果。无奈之下，我决定放弃 Docker 安装方式，直接安装 server 版本的 Jellyfin。

2. 安装 server 版本的 Jellyfin：在终端中输入命令 curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash，安装过程非常顺利。

3. 配置 Jellyfin：安装完成后，通过浏览器访问 http://192.168.10.100:8096 进入配置页面。在添加媒体库这里，我遇到了一个麻烦，网页只能选择到 /home/bddxg 目录，无法继续往下选择到我的媒体库位置 /home/bddxg/nas。于是我向 deepseek 求助，它告诉我需要执行命令:

   sudo usermod -aG bddxg jellyfin
   
   # 并且重启 Jellyfin 服务
   
   sudo systemctl restart jellyfin
   
   

   按照它的建议操作后，我刷新了网页，重新配置了 Jellyfin，终于可以正常添加媒体库了。

4. 电视端播放：在电视上安装好 Jellyfin apk 客户端后，现在终于可以正常读取 Ubuntu 服务器上的影视资源了，坐在沙发上，享受着大屏观影的乐趣，这种感觉真的太棒了！

 通过这次折腾，我成功地让闲置的 Ubuntu 服务器重新焕发生机，变成了一个功能强大的家庭影院。希望我的经验能够对大家有所帮助，也欢迎大家一起交流更多关于服务器利用和家庭影院搭建的经验。

[!WARNING] 令人遗憾的是,目前 jellyfin 似乎不支持rmvb 格式的影片, 下载资源的时候注意影片格式,推荐直接下载 mp4 格式的资源

---

本次使用到的软件名称和版本如下:

软件名	版本号	安装命令
samba	Version 4.19.5-Ubuntu	sudo apt-get install samba samba-common
jellyfin	Jellyfin.Server 10.10.6.0	curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash
ffmpeg(jellyfin 内自带)	ffmpeg version 7.0.2-Jellyfin	null

作者：冰冻大西瓜
来源：juejin.cn/post/7476614823883833382

在 MyBatis 中，如果 Mapper 接口的方法有多个参数，但没有使用 @Param 注解，默认情况下，MyBatis 会将这些参数放入一个 Map 中，键名为 param1、param2 等，或者使用索引 0、1 等来访问。以下是具体的使用方法和注意事项。

一、Mapper 接口方法

假设有一个 Mapper 接口方法，包含多个参数但没有使用 @Param 注解：

public interface UserMapper {

    User selectUserByNameAndAge(String name, int age);

}

二、XML 文件中的参数引用

在 XML 文件中，可以通过以下方式引用参数：

1. 使用 param1、param2 等

MyBatis 会自动为参数生成键名 param1、param2 等：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{param1} AND age = #{param2}

</select>

2. 使用索引 0、1 等

也可以通过索引 0、1 等来引用参数：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{0} AND age = #{1}

</select>

三、注意事项

四、示例代码

1. Mapper 接口

public interface UserMapper {

    User selectUserByNameAndAge(String name, int age);

}

2. XML 文件

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{param1} AND age = #{param2}

</select>

或者：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{0} AND age = #{1}

</select>

3. 测试代码

SqlSession sqlSession = sqlSessionFactory.openSession();

UserMapper mapper = sqlSession.getMapper(UserMapper.class);

User user = mapper.selectUserByNameAndAge("John", 25);

System.out.println(user);

sqlSession.close();

• 如果 Mapper 接口方法有多个参数且没有使用 @Param 注解，可以通过 param1、param2 或索引 0、1 等方式引用参数。


• 这种方式可读性较差，容易出错，推荐使用 @Param 注解明确参数名称。


• 使用 @Param 注解后，XML 文件中的参数引用会更加清晰和易于维护。

作为Java后端开发者转向游戏后端开发，虽然核心编程能力相通，但游戏开发在架构设计、协议选择、实时性处理等方面有显著差异。以下从实际工作流程角度详细说明游戏后端开发的核心要点及前后端协作流程：

一、游戏后端核心职责

二、开发全流程实战（以MMORPG为例）

阶段1：预研设计（2-4周）

• 协议设计
  

  // 使用Protobuf定义移动协议
  
  message PlayerMove {
  
    int32 player_id = 1;
  
    Vector3 position = 2;  // 三维坐标
  
    float rotation = 3;    // 朝向
  
    int64 timestamp = 4;   // 客户端时间戳
  
  }
  
  
  
  message BattleSkill {
  
    int32 skill_id = 1;
  
    repeated int32 target_ids = 2;  // 多目标锁定
  
    Coordinate cast_position = 3;   // 技能释放位置
  
  }
  
  

  
  


• 架构设计
  

  graph TD
  
    A[Gateway] --> B[BattleServer]
  
    A --> C[SocialServer]
  
    B --> D[RedisCluster]
  
    C --> E[MySQLCluster]
  
    F[MatchService] --> B
  
  

  
  

阶段2：核心系统开发（6-8周）

三、前后端协作关键点

四、性能优化实践

五、上线后运维

六、常见问题解决方案

问题场景：战斗不同步

排查步骤：

问题场景：登录排队

优化方案：

通过以上流程，Java后端开发者可逐步掌握游戏开发特性，重点需要转变的思维模式包括：从请求响应模式到实时状态同步、从CRUD主导到复杂逻辑计算、从分钟级延迟到毫秒级响应的要求。建议从简单的棋牌类游戏入手，逐步过渡到大型实时游戏开发。

😃文章首发于公众号[精益码农]。

闭包作为前端面试的必考题目，常让1-3年工作经验的Javascripter感到困惑，我的主力语言C#/GO均有闭包。

1. 闭包：关键点在于函数是否捕获了其外部作用域的变量

闭包的形成： 定义函数时， 函数引用了其外部作用域的变量， 之后就形成了闭包。

闭包的结果： 引用的变量和定义的函数都会一同存在（即使已经脱离了函数定义/引用的变量的作用域），一直到闭包被消灭。

    public  static Action Closure()

    {

      var x = 1;

      Action action= () =>

         {

             var y = 1;

             var result = x + y;

             Console.WriteLine(result);

             x++;

         };

         return action;

    }



public static void  Main() {

       var  a=Closure();

        a();

        a();

}

 //  调用函数输出

  2

  3

委托action是一个函数，它使用了“x”这个外部作用域的变量（x变量不是函数内局部变量），变量引用将被捕获形成闭包。

即使action被返回了（即使“x”已经脱离了它被引用时的作用域环境（Closure）），但是两次执行能输出2,3 说明它脱离原引用环境仍然能用。

当你在代码调试器（debugger）里观察“action”时，可以看到一个Target属性，里面封装了捕获的x变量：

实际上，委托，匿名函数和lambda都是继承自Delegate类，
Delegate不允许开发者直接使用，只有编译器才能使用， 也就是说delegate Action都是语法糖。

• Method：MethodInfo反射类型- 方法执行体


• Target：当前委托执行的对象，这些语法糖由编译器生成了继承自Delegate类型的对象，包含了捕获的自由变量。

再给一个反例：

public class Program

{

    private static int x = 1; // 静态字段

    public static void Main()

    {

        var  action = NoClosure();

        action();

        action(); 

    }

    

   public  static Action NoClosure(){

        Action action=()=>{

            var  y =1;

            var sum = x+y;

            Console.WriteLine($"sum = { sum }");

            x++;

        };

        return action;

    }

}

x 是静态字段，在程序中有独立的存储区域， 不在线程的函数堆栈区，不属于某个特定的作用域。

匿名函数使用了 x，但没有捕获外部作用域的变量，因此不构成闭包， Target属性对象无捕获的字段。

从编程设计的角度：闭包开创了除全局变量传值， 函数参数传值之外的第三种变量使用方式。

2. 闭包的形成时机和效果

闭包是词法闭包的简称，维基百科上是这样定义的：

“在计算机科学中，闭包是在词法环境中绑定自由变量的一等函数”。

闭包的形成时机：

• 一等函数


• 外部作用域变量

闭包的形态：

会捕获闭包函数内引用的外部作用域变量， 一直持有，直到闭包函数不再使用被销毁。

内部实现是形成了一个对象(包含执行函数和捕获的变量，参考Target对象), 只有形成堆内存，才有后续闭包销毁的行为，当闭包这个对象不再被引用时，闭包被GC清理。

闭包的作用周期：

离不开作用域这个概念，函数理所当然管控了函数内的局部变量作用域，但当它引用了外部有作用域的变量时， 就形成了闭包函数。
当闭包（例如一个委托或 lambda 表达式）不再被任何变量、对象或事件持有引用时，它就变成了“不可达”对象， 闭包被gc清理，其实就是堆内存被清理。

2.1 一等函数

一等函数很容易理解，就是在各语言， 函数被认为是某类数据类型， 定义函数就成了定义变量， 函数也可以像变量一样被传递。

很明显，在C#中我们常使用的匿名函数、lambda表达式都是一等函数。

Func<string,string> myFunc = delegate(string var1)

                                {

                                    return "some value";   

                                };

Func<string,string> myFunc = var1 => "some value";  



string myVar = myFunc("something");

2.2 自由变量

在函数中被引用的外部作用域变量， 注意， 这个变量是外部有作用域的变量，也就说排除全局变量（这些变量在程序的独立区域， 不属于任何作用域）。

public void Test() 

{

       var myVar = "this is good";

       Func<string,string> myFunc = delegate(string var1)

                                {

                                    return var1 + myVar;   

                                };

}

上面这个示例，myFunc形成了闭包，捕获了myVar这个外部作用域的变量；
即使Test函数返回了委托myFunc（脱离了定义myVar变量的作用域），闭包依然持有myVar的变量引用，
注意，引用变量，并不是使用当时变量的副本值。

我们再回过头来看结合了线程调度的闭包面试题。

3. 闭包函数关联线程调度： 依次打印连续的数字

 static void Closure1()

{

    for (int i = 0; i < 10; i++)

    {                 

         Task.Run(()=> Console.WriteLine(i));

    }

 }

每次输出数字不固定

并不是预期的 0.1.2.3.4.5.6.7.8.9

首先形成了闭包函数()=> Console.WriteLine(i)， 捕获了外部有作用域变量i的引用, 此处捕获的变量i相对于函数是全局变量。
但是Task调度闭包函数的时机不确定， 所以打印的是被调度时引用的变量i值。

数字符合但乱序：为每个闭包函数绑定独立变量

循环内增加局部变量， 解绑全局变量 （或者可以换成foreach，foreach相当于内部给你整了一个局部变量）。

能输出乱序的0,1,2,3,4,5,6,7,8,9

因为每次循环内产生的闭包函数捕获了对应的局部变量j，这样每个任务执行环境均独立维护了一个变量j， 这个j不是全局变量, 但是由于Task启动时机依然不确定，故是乱序。

数字符合且有序

核心是解决 Task调度问题。

思路是：一个共享变量，每个任务打印该变量自增的一个阶段，但是该自增不允许被打断。

 public static void Main(string[] args)

    {

        var s =0;

        var  lo = new Program();

        for (int i = 0; i < 10; i++)

        {              

           Task.Run(()=> 

            { 

                lock(lo)

                {

                    Console.WriteLine(s);   // 依然形成了闭包函数， 之后闭包函数被线程调度

                    s++;

                }                

            });

        }

        Thread.Sleep(2000);

    }  // 上面是一个明显的锁争用

3.Golang闭包的应用

gin 框架中中间件的默认形态是：

package middleware

func AuthenticationMiddleware(c *gin.Context) {

   ......

}



 //  Use方法的参数签名是这样：  type HandlerFunc func(*Context)， 不支持入参

router.Use(middleware.AuthenticationMiddleware)   

实际实践上我们又需要给中间件传参， 闭包提供了这一能力。

func Authentication2Middleware(log *zap.Logger) gin.HandlerFunc  {

     return func(c *gin.Context) { 

         ...    这里面可以利用log 参数。

     }

}



var logger  *zap.Logger

api.Use(middleware.Authentication2Middleware(logger))

总结

本文屏蔽语言差异，理清了[闭包]的概念核心： 函数引用了其外部作用域的变量，

核心特征：一等函数、自由变量，核心结果： 即使脱离了原捕获变量的原作用域，闭包函数依然持有该变量引用。

不仅能帮助我们应对多语种有关闭包的面试题， 也帮助我们了解[闭包]在通用语言中的设计初衷。

另外我们通过C# 调试器巩固了Delegate 抽象类，这是lambda表达式,委托，匿名函数的底层抽象数据结构类，包含两个重要属性 Method Target，分别表征了方法执行体、当前委托作用的对象，

可想而知，其他语言也是通过这个机制捕获闭包当中的自由变量。

一、为什么需要AI代码审查？

写代码就像做饭，即使是最有经验的厨师（程序员），也难免会忘记关火（资源未释放）、放错调料（逻辑错误）或者切到手（空指针异常）。Deepseek就像一位24小时待命的厨房监理，能帮我们实时发现这些"安全隐患"。

二、环境准备（5分钟搞定）

1. 安装Deepseek插件（以VSCode为例）：

• • 插件市场搜索"Deepseek Code Review"
  • 点击安装（就像安装手机APP一样简单）

2. Java项目配置：

<dependency>

    <groupId>com.deepseekgroupId>

    <artifactId>code-analyzerartifactId>

    <version>1.3.0version>

dependency>

三、真实案例：用户管理系统漏洞检测

原始问题代码：

public class UserService {

    // 漏洞1：未处理空指针

    public String getUserRole(String userId) {

        return UserDB.query(userId).getRole();

    }



    // 漏洞2：资源未关闭

    public void exportUsers() {

        FileOutputStream fos = new FileOutputStream("users.csv");

        fos.write(getAllUsers().getBytes());

    }



    // 漏洞3：SQL注入风险

    public void deleteUser(String input) {

        Statement stmt = conn.createStatement();

        stmt.execute("DELETE FROM users WHERE id = " + input);

    }

}

使用Deepseek审查后：

智能修复建议：

1. 空指针防护 → 建议添加Optional处理
2. 流资源 → 推荐try-with-resources语法
3. SQL注入 → 提示改用PreparedStatement

修正后的代码：

public class UserService {

    // 修复1：Optional处理空指针

    public String getUserRole(String userId) {

        return Optional.ofNullable(UserDB.query(userId))

                      .map(User::getRole)

                      .orElse("guest");

    }



    // 修复2：自动资源管理

    public void exportUsers() {

        try (FileOutputStream fos = new FileOutputStream("users.csv")) {

            fos.write(getAllUsers().getBytes());

        }

    }



    // 修复3：预编译防注入

    public void deleteUser(String input) {

        PreparedStatement pstmt = conn.prepareStatement(

            "DELETE FROM users WHERE id = ?");

        pstmt.setString(1, input);

        pstmt.executeUpdate();

    }

}

四、实现原理揭秘

Deepseek的代码审查就像"X光扫描仪"，通过以下三步工作：

1. 模式识别：比对数千万个代码样本

• • 就像老师批改作业时发现常见错误

2. 上下文理解：分析代码的"人际关系"

• • 数据库连接有没有"成对出现"（打开/关闭）
  • 敏感操作有没有"保镖"（权限校验）

3. 智能推理：预测代码的"未来"

• • 这个变量走到这里会不会变成null？
  • 这个循环会不会变成"无限列车"？

五、进阶使用技巧

1. 自定义审查规则（配置文件示例）：

rules:

  security:

    sql_injection: error

  performance:

    loop_complexity: warning

  style:

    var_naming: info

2. 与CI/CD集成（GitHub Action示例）：

- name: Deepseek Code Review

  uses: deepseek-ai/code-review-action@v2

  with:

    severity_level: warning

    fail_on: error

六、开发者常见疑问

Q：AI会不会误判我的代码？
A：就像导航偶尔会绕路，Deepseek给出的是"建议"而非"判决"，最终决策权在你手中

Q：处理历史遗留项目要多久？
A：10万行代码项目约需3-5分钟，支持增量扫描

七、效果对比数据

指标	人工审查	Deepseek+人工
平均耗时	4小时	30分钟
漏洞发现率	78%	95%
误报率	5%	12%
知识库更新速度	季度	实时

作者：Java技术小馆
来源：juejin.cn/post/7473799336675639308

Typora 是一款广受欢迎的 Markdown 编辑器，以其所见即所得的编辑模式和优雅的界面而闻名，长期以来是许多 Markdown 用户的首选。然而，从 2021 年起，Typora 不再免费，采用一次性付费授权模式。虽然费用不高，但对于轻量使用者或预算有限的用户可能并不友好。

今天来推荐一款开源替代品，一款更加轻量化、注重隐私且完全免费的 Markdown 编辑器，专为 macOS 用户开发。

项目介绍

MarkEdit 是一款轻量级且高效的 Markdown 编辑器，专为 macOS 用户设计，安装包大小不到 3 MB。它以简洁的设计和流畅的性能，成为技术写作、笔记记录、博客创作以及项目文档编辑的理想工具。无论是编写技术文档、撰写博客文章，还是编辑 README 文件，MarkEdit 都能以快速响应和便捷操作帮助用户专注于内容创作。

根据官方介绍，MarkEdit 免费的原因如下:

MarkEdit 是完全免费和开源的，没有任何广告或其他服务。我们之所以发布它，是因为我们喜欢它，我们不期望从中获得任何收入。

功能特性

MarkEdit 的核心功能围绕 Markdown 写作展开，注重实用与高效，以下是其主要特性：

• 实时语法高亮：清晰呈现 Markdown 的结构，让文档层次分明。


• 多种主题：提供不同的配色方案，总有一种适合你。


• 分屏实时预览：支持所见即所得的写作体验，左侧编辑，右侧实时渲染。


• 文件树视图：适合多文件项目管理，方便在项目间快速切换。


• 文档导出：支持将 Markdown 文件导出为 PDF 或 HTML 格式，方便分享和发布。


• CodeMirror 插件支持：通过插件扩展功能，满足更多 Markdown 使用需求。


• ......

MarkEdit 的特点让它能胜任多种写作场合：

• 技术文档：帮助开发者快速记录项目相关文档。


• 博客创作：支持实时预览，让博客排版更直观。


• 个人笔记：轻量且启动迅速，适合日常记录。


• 项目文档：文件管理功能让多文件项目的编辑更加高效。

效果展示

多种主题风格，总有一种适合你：

实时预览，让博客排版更直观：

设置界面，清晰直观：

安装方法

方法 1：安装包下载

找到 MarkEdit 的最新版本安装包下载使用即可，地址：github.com/MarkEdit-ap… 。

方法 2：通过 Homebrew

在终端中运行相关命令即可完成安装。

brew install markedit

注意：MarkEdit 支持 macOS Sonoma 和 macOS Sequoia， 历史兼容版本包括 macOS 12 和 macOS 13。

总结

MarkEdit 是一款专注于 Markdown 写作的 macOS 原生编辑器，以简洁、高效、隐私友好为核心设计理念。无论是日常写作还是处理复杂文档，它都能提供流畅的体验和强大的功能。对于追求高效写作的 macOS 用户来说，MarkEdit 是一个不可多得的优秀工具。

项目地址：github.com/MarkEdit-ap… 。

前言

• 常网IT源码上线啦！


• 本篇录入吊打面试官专栏，希望能祝君拿下Offer一臂之力，各位看官感兴趣可移步🚶。


• 有人说面试造火箭，进去拧螺丝；其实个人觉得问的问题是项目中涉及的点 || 热门的技术栈都是很好的面试体验，不要是旁门左道冷门的知识，实际上并不会用到的。


• 接下来想分享一些自己在项目中遇到的技术选型以及问题场景。

你生命的前半辈子或许属于别人，活在别人的认为里。那把后半辈子还给你自己，去追随你内在的声音。

一、前言

之前在讨论设计模式、算法的时候，一个后端组长冷嘲热讽的说：前端哪有什么设计模式、算法，就好像只有后端语言有一样，至今还记得那不屑的眼神。

今天想起来，就随便列几个，给这位眼里前端无设计模式的人，睁眼看世界。

二、观察者模式 (Observer Pattern)

观察者模式的核心是当数据发生变化时，自动通知并更新相关的视图。在 Vue 中，这通过其响应式系统实现。

Vue 2.x：Object.defineProperty

在 Vue 2.x 中，响应式系统是通过 Object.defineProperty 实现的。每当访问某个对象的属性时，getter 会被触发；当设置属性时，setter 会触发，从而实现数据更新时视图的重新渲染。

源码（简化版）：

function defineReactive(obj, key, val) {

  // 创建一个 dep 实例，用于收集依赖

  const dep = new Dep();



  Object.defineProperty(obj, key, {

    get() {

      // 当访问属性时，触发 getter，并把当前 watcher 依赖收集到 dep 中

      if (Dep.target) {

        dep.addDep(Dep.target);

      }

      return val;

    },

    set(newVal) {

      if (newVal !== val) {

        val = newVal;

        dep.notify(); // 数据更新时，通知所有依赖重新渲染

      }

    }

  });

}

• Dep 类：它管理依赖，addDep 用于添加依赖，notify 用于通知所有依赖更新。

class Dep {

  constructor() {

    this.deps = [];

  }



  addDep(dep) {

    this.deps.push(dep);

  }



  notify() {

    this.deps.forEach(dep => dep.update());

  }

}

• 依赖收集：当 Vue 组件渲染时，会创建一个 watcher 对象，表示一个视图的更新需求。当视图渲染过程中访问数据时，getter 会触发，并将 watcher 添加到 dep 的依赖列表中。

Vue 3.x：Proxy

Vue 3.x 使用了 Proxy 来替代 Object.defineProperty，从而实现了更高效的响应式机制，支持深度代理。

源码（简化版）：

function reactive(target) {

  const handler = {

    get(target, key) {

      // 依赖收集：当访问某个属性时，触发 getter，收集依赖

      track(target, key);

      return target[key];

    },

    set(target, key, value) {

      // 数据更新时，通知相关的视图更新

      target[key] = value;

      trigger(target, key);

      return true;

    }

  };



  return new Proxy(target, handler);

}

• track：收集依赖，确保只有相关组件更新。


• trigger：当数据发生变化时，通知所有依赖重新渲染。

三、发布/订阅模式 (Publish/Subscribe Pattern)

发布/订阅模式通过中央事件总线（Event Bus）实现不同组件间的解耦，Vue 2.x 中，组件间的通信就是基于这种模式实现的。

Vue 2.x：事件总线（Event Bus）

事件总线就是一个中央的事件处理器，Vue 实例可以充当事件总线，用来处理不同组件之间的消息传递。

// 创建一个 Vue 实例作为事件总线

const EventBus = new Vue();



// 组件 A 发布事件

EventBus.$emit('message', 'Hello from A');



// 组件 B 订阅事件

EventBus.$on('message', (msg) => {

  console.log(msg); // 输出 'Hello from A'

});

• $emit：用于发布事件。


• $on：用于订阅事件。


• $off：用于取消订阅事件。

四、工厂模式 (Factory Pattern)

工厂模式通过一个函数生成对象或实例，Vue 的组件化机制和动态组件加载就是通过工厂模式来实现的。

Vue 的 render 函数和 functional 组件支持动态生成组件实例。例如，functional 组件本质上是一个工厂函数，通过给定的 props 返回一个 VNode。

Vue.component('dynamic-component', {

  functional: true,

  render(h, context) {

    // 工厂模式：根据传入的 props 创建不同的 VNode

    return h(context.props.type);

  }

});

• functional 组件：它没有实例，所有的逻辑都是在 render 函数中处理，返回的 VNode 就是组件的“产物”。

五、单例模式 (Singleton Pattern)

单例模式确保某个类只有一个实例，Vue 实例就是全局唯一的。

在 Vue 中，全局的 Vue 构造函数本身就是一个单例对象，通常只会创建一个 Vue 实例，用于管理应用的生命周期和全局配置。

const app = new Vue({

  data: {

    message: 'Hello, Vue!'

  }

});

• 单例保证：整个应用只有一个 Vue 实例，所有全局的配置（如 Vue.config）都是共享的。

六、模板方法模式 (Template Method Pattern)

模板方法模式定义了一个操作中的算法框架，而将一些步骤延迟到子类中。Vue 的生命周期钩子就是一个模板方法模式的实现。

Vue 定义了一系列生命周期钩子（如 created、mounted、updated 等），它们实现了组件从创建到销毁的完整过程。开发者可以在这些钩子中插入自定义逻辑。

Vue.component('my-component', {

  data() {

    return {

      message: 'Hello, 泽!'

    };

  },

  created() {

    console.log('Component created');

  },

  mounted() {

    console.log('Component mounted');

  },

  template: '<div>{{ message }}</div>'

});

Vue 组件的生命周期钩子实现了模板方法模式的核心思想，开发者可以根据需要重写生命周期钩子，而 Vue 保证生命周期的流程和框架。

七、策略模式 (Strategy Pattern)

策略模式通过定义一系列算法，将它们封装起来，使它们可以相互替换。Vue 的 计算属性（computed） 和 方法（methods） 可以看作是策略模式的应用。

计算属性允许我们定义动态的属性，其值是基于其他属性的计算结果。Vue 会根据依赖关系缓存计算结果，只有在依赖的属性发生变化时，计算属性才会重新计算。

new Vue({

  data() {

    return {

      num1: 10,

      num2: 20

    };

  },

  computed: {

    sum() {

      return this.num1 + this.num2;

    }

  }

});

八、装饰器模式 (Decorator Pattern)

装饰器模式允许动态地给对象添加功能，而无需改变其结构。在 Vue 中，指令就是一种装饰器模式的应用，它通过指令来动态地改变元素的行为。

<div v-bind:class="className"></div>

<div v-if="isVisible">谁的疯太谍</div>

这些指令动态地修改 DOM 元素的行为，类似于装饰器在不修改对象结构的情况下，动态地增强其功能。

九、代理模式 (Proxy Pattern)

代理模式通过创建一个代理对象来控制对目标对象的访问。在 Vue 3.x 中，响应式系统就是通过 Proxy 来代理对象的访问。

vue3

const state = reactive({

  count: 0

});



state.count++; // 会触发依赖更新

reactive：使用 Proxy 对对象进行代理，当对象的属性被访问或修改时，都会触发代理器的 get 和 set 操作。

function reactive(target) {

  const handler = {

    get(target, key) {

      // 依赖收集：当访问某个属性时，触发 getter，收集依赖

      track(target, key);

      return target[key];

    },

    set(target, key, value) {

      // 数据更新时，触发依赖更新

      target[key] = value;

      trigger(target, key);

      return true;

    }

  };



  return new Proxy(target, handler);

}

• track：当读取目标对象的属性时，收集依赖，这通常涉及到将当前的 watcher 加入到依赖列表中。


• trigger：当对象的属性发生改变时，通知所有相关的依赖（如组件）更新。

这个 Proxy 机制使得 Vue 可以动态地观察和更新对象的变化，比 Object.defineProperty 更具灵活性。

十、适配器模式 (Adapter Pattern)

适配器模式用于将一个类的接口转换成客户端期望的另一个接口，使得原本不兼容的接口可以一起工作。Vue 的插槽（Slots）和组件的跨平台支持某种程度上借用了适配器模式的思想。

Vue 插槽机制

Vue 的插槽机制是通过提供一个适配层，将父组件传入的内容插入到子组件的指定位置。开发者可以使用具名插槽、作用域插槽等方式，实现灵活的插槽传递。

<template>

  <child-component>

    <template #header>

      <h1>This is the header</h1>

    </template>

    <p>This is the default content</p>

  </child-component>

</template>

父组件通过 #header 插槽插入了一个标题内容，而 child-component 会将其插入到适当的位置。这里，插槽充当了一个适配器，允许父组件插入的内容与子组件的内容结构灵活匹配。

十全十美

至此撒花~

后记

我相信技术不分界，不深入了解，就不要轻易断言。

一个圆，有了一个缺口，不知道的东西就更多了。

但是没有缺口，不知道的东西就少了。

这也就是为什么，知道得越多，不知道的就越多。

谢谢！

最后，祝君能拿下满意的offer。

我是Dignity_呱，来交个朋友呀，有朋自远方来，不亦乐乎呀！深夜末班车

👍 如果对您有帮助，您的点赞是我前进的润滑剂。

以往推荐

小小导出，我大前端足矣！

靓仔，说一下keep-alive缓存组件后怎么更新及原理？

面试官问我watch和computed的区别以及选择？

面试官问我new Vue阶段做了什么？

前端仔，快把dist部署到Nginx上

多图详解，一次性啃懂原型链（上万字）

Vue-Cli3搭建组件库

Vue实现动态路由（和面试官吹项目亮点）

项目中你不知道的Axios骚操作（手写核心原理、兼容性）

VuePress搭建项目组件文档

原文链接

juejin.cn/post/744421…

作为一名后端开发，我们经常需要使用终端工具来管理Linux服务器。最近发现一款比Xshell更好用终端工具XPipe，能支持SSH、Docker、K8S等多种环境，还具有强大的文件管理工具，分享给大家！

XPipe简介

XPipe是一款全新的终端管理工具，具有强大的文件管理功能，目前在Github上已有4.8k+Star。它可以基于你本地安装的命令行工具（例如PowerShell）来执行远程命令，反应速度非常快。如果你有使用 ssh、docker、kubectl 等命令行工具来管理服务器的需求，使用它就可以了。

XPipe具有如下特性：

• 连接中心：能轻松实现所有类型的远程连接，支持SSH、Docker、Podman、Kubernetes、Powershell等环境。


• 强大的文件管理功能：具有对远程系统专门优化的文件管理功能。


• 多种命令行环境支持：包括bash、zsh、cmd、PowerShell等。


• 多功能脚本系统：可以方便地管理可重用脚本。


• 密码保险箱：所有远程连接账户均完全存储于您本地系统中的一个加密安全的存储库中。

下面是XPipe使用过程中的截图，界面还是挺炫酷的！

这或许是一个对你有用的开源项目，mall项目是一套基于 SpringBoot3 + Vue 的电商系统（Github标星60K），后端支持多模块和2024最新微服务架构 ，采用Docker和K8S部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能！

• Boot项目：github.com/macrozheng/…


• Cloud项目：github.com/macrozheng/…


• 教程网站：http://www.macrozheng.com

项目演示：

使用

• 首先去XPipe的Release页面下载它的安装包，我这里下载的是Portable版本，解压即可使用，地址：github.com/xpipe-io/xp…

• 下载完成后进行解压，解压后双击xpiped.exe即可使用；

• 这里我们先进行一些设置，将语言设置成中文，然后设置下主题，个人比较喜欢黑色主题；

• 接下来新建一个SSH连接，输入服务器地址后，选择添加预定义身份；

• 这个预定义身份相当于一个可重用的Linux访问账户；

• 然后输入连接名称，点击完成即可创建连接；

• 我们可以发现XPipe能自动发现服务器器上的Docker环境并创建连接选项，如果你安装了K8S环境的话，也是可以发现到的；

• 然后我们单击下Linux-local这个连接，就可以通过本地命令行工具来管理Linux服务器了；

• 如果你想连接到某个Docker容器的话，直接点击对应容器即可连接，这里以mysql为例；

• 选中左侧远程服务器，点击右侧的文件浏览器按钮可以直接管理远程服务器上的文件，非常方便；

• 在所有脚本功能中，可以存储我们的可重用脚本；

• 在所有身份中存储着我们的账号密码，之前创建的Linux root账户在这里可以进行修改。

总结

今天给大家分享了一款好用的终端工具XPipe，界面炫酷功能强大，它的文件管理功能确实惊艳到我了。而且它可以用本地命令行工具来执行SSH命令，对比一些套壳的跨平台终端工具，反应速度还是非常快的！

项目地址

github.com/xpipe-io/xp…

前言

不久前，被人问到Java 泛型中的通配符 T，E，K，V，? 是什么？有什么用？这不经让我有些回忆起该开始学习Java那段日子，那是对泛型什么的其实有些迷迷糊糊的，学的不这么样，是在做项目的过程中，渐渐有又看到别人的代码、在看源码的时候老是遇见，之后就专门去了解学习，才对这几个通配符 T，E，K，V，?有所了解。

泛型有什么用？

在介绍这几个通配符之前，我们先介绍介绍泛型，看看泛型带给我们的好处。
Java泛型是JDK5中引入的一个新特性，泛型提供了编译是类型安全检测机制，这个机制允许开发者在编译是检测非法类型。泛型的本质就是参数化类型，就是在编译时对输入的参数指定一个数据类型。

1. 类型安全：编译是检查类型是否匹配，避免了ClassCastexception的发生。

解释
  // 非泛型写法（存在类型转换风险）

  List list1 = new ArrayList();

  list1.add("a");

  Integer num = (Long) list1.get(0);  // 运行时抛出 ClassCastException



  // 泛型写法（编译时检查类型）

  List list2 = new ArrayList<>();

  // list.add(1);       // 编译报错

  list2.add("a");

  String str = list2.get(0); // 无需强制转换 

2. 消除代码强制类型转换：减少了一些类型转换操作。

// 非泛型写法

Map map1 = new HashMap();

map1.put("user", new User());

User user1 = (User) map1.get("user");



// 泛型写法

Map map2 = new HashMap<>();

map2.put("user", new User());

// 自动转换

User user2 = map2.get("user");

3.代码复用：可以支持多种数据类型，不要重复编写代码，例如：我们常用的统一响应结果类。

@Data

@NoArgsConstructor

@AllArgsConstructor

public class Result {

    /**

     * 响应状态码

     */

    private int code;



    /**

     * 响应信息

     */

    private String message;



    /**

     * 响应数据

     */

    private T data;



    /**

     * 时间戳

     */

    private long timestamp;

    其他代码省略...

4. 增强可读性：通过类型参数就直接能看出要填入什么类型。

List list = new ArrayList<>();

泛型里的通配符

我们在使用泛型的时候，经常会使用或者看见多种不同的通配符，常见的 T，E，K，V，?这几种，相信大家一定不陌生，但是真的问你他们有什么作用？有什么区别时，很多人应该是不能很好的介绍它们的，接下来我就来给大家介绍介绍。

T，E，K，V

1. T（Type） T表示任意类型参数，我们举个例子

pubile class A{

    prvate T t;

    //其他省略...

}



//创建一个不带泛型参数的A

    A a = new A();

    a.set(new B());

    B b = (B) a.get();//需要进行强制类型转换



//创建一个带泛型参数的A

    A a = new A();

    a.set(new B());

    B b = a.get();

2. E(Element) E表示集合中的元素类型

List list = new ArrayList<>();

3. K(Key) K表示映射的键的数据类型

Map map = new HashMap<>();

4. V(Value) V表示映射的值的数据类型

Map map = new HashMap<>();