在 Spring Boot 应用中使用 @ServerEndpoint 实现 WebSocket 通信是一种常见方式。@ServerEndpoint 是 Java EE 提供的注解，通常需要配合 javax.websocket API 使用。Spring Boot 本身并不直接管理 @ServerEndpoint，但可以通过一些技巧让它与 Spring 环境集成，同时实现客户端识别和管理。 本文将介绍如何在 Spring Boot 应用中使用 @ServerEndpoint 注解实现 WebSocket 通信，并实现对客户端的识别与管理。 项目依赖配置首先，在 pom.xml 中添加必要的依赖： 1234567<dependencies> <!-- Spring Boot WebSocket 支持 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-start ...

“正规军”和“地下党” 如果说数组是纪律严明的 🪖 “正规军”，那么链表就是灵活多变的“地下党”。 地下党借助 📞 单线联络的方式，灵活隐秘地传递着各种重要信息。在计算机科学领域里，有一种数据结构也恰恰具备这样的特征，这种数据结构就是 ⛓️ 链表。 单向链表链表是什么样子的？为什么说它像地下党呢？我们先来看看单向链表的结构。 链表是一种在物理上非连续、非顺序的数据结构，由若干节点所组成。 单向链表的每一个节点包含两部分，一部分是存放数据的的变量data，另一部分是指向下一个节点的指针next。 1234private static class Node{ int data; Node next;} 链表的第一个节点被称为头节点，最后一个节点被称为尾节点，尾节点的next指针指向空。 与数组按照下标来随机寻找元素不同，对于寻找链表的其中一个节点X，我们只能根据头节点A的next指针来找到该节点的下一个节点B，再根据节点B的next指针来找到该节点的下一个节点C…… 这正如地下党的联络方式，一级一级，单线传递。 相对于数组而言，链表因层级分明导致其 ...

基本概念 数组是一种数据结构，是有限个相同类型的变量所组成的有序集合，数组中的每一个变量被称为元素。 以整型数组为例，数组的存储形式如下图所示： 数据 2 3 6 1 4 0 6 8 2 下标 0 1 2 3 4 5 6 7 8 如你所见，数组的每一个元素都存在一个相应的“编号”，就是下标。下标从0开始，一直到数组的长度-1。 数组在内存中是顺序存储的，而内存是由一个个连续的内存单元组成，每一个内存单元都有自己的地址。数组中的每一元素都存储在内存单元中，而且元素之间紧密排列，既不能打乱元素的存储顺序，也不能跳过某个存储单元进行存储。 在上图中，巧克力黄色的格子代表空闲的存储单元，灰色的格子代表已占用的存储单元，而淡绿色的连续格子代表数组在内存中的位置。 读取元素读取元素是数组最简单的操作，由于数组在内存中顺序存储，所以只要给出一个数组下标，就可以读取到对应的数组元素。 假设有一个名为array的数组，想要读取数组下标为4的元素，就写作array[4]。 值得注意的是，输入的下标必须在数组的长度范围之内，否则会出现数组越界！如果数组的长度为x，输入的下标为y，那么结合 ...

一提到抽奖，很多人就会联想到随机数这个东西。是的没错，那么怎么样既能实现随机的抽奖，又可以人为的控制每个奖品的概率呢？往下看。 解决思路Tip：在实际的业务场景中，对于奖品概率的配置往往不是直接输入对应的百分比，而是权重，该值的取值范围大于等于0即可，那么对应的奖品概率=奖品权重/所有奖品权重合计。这样做的目的，是在配置时不需要输入通过人工精确分配的概率百分比，同时也可以规避总概率不等于100%的人为问题。 解决思路的灵感来源于扇形统计图和转盘抽奖，某一项占比越大，那么在圆形上占用的面积越多，在旋转后被抽中的概率也就越大。我们可以把圆形展开，变成一条线段或者一个矩形，根据奖品各自的概率（权重）分配其所占用的面积。假设我们的手指就是转盘抽奖上的指针，此时，手指随机落在某个奖品区间内的概率与他的区间大小是息息相关的。 上图中，我们暂且称0,20,60,110,125为节点，那么节点0-20为奖品1所在区域，20-60为奖品2所在区域，60-110为奖品3所在区域，110-125为奖品4所在区域。此时，生成一个0-125的随机数x，那么x的值在哪个奖品的区间内，抽中的就是哪个奖品。 代码实 ...

在 Java 中，把List 转换为多级的树形结构非常常见。例如菜单数据是在数据库中“平铺”存储的，在做查询时，需要将其转换为树形结构，方便前端进行展示。 本文就以菜单作为案例，读者可以举一反三，实现自己的需求 数据库设计将其命名为PERMISSIONS 字段名 类型 注释 CODE varchar 编码(主键) PARENT_CODE varchar 父编码 NAME varchar 名称 TYPE tinyint 类型 0菜单 1按钮 2接口 URL varchar 前端路由或后端接口路由 CREATE_TIME datetime 创建时间 UPDATE_TIME datetime 更新时间 Java 处理假设我们此时已经查询出一个列表List<Permissions>，Permissions类是与数据库对应的实体类，包含了PERMISSIONS表的所有字段，此刻就需要对其进行树形结构处理。 树形结构实体类首先我们需要一个包含自身的树形结构实体类 1234567891011121314151617/** * 权限树内容 */@Da ...

标准规范的接口可以降低前后端开发人员之间的沟通成本，并且能够降低后端服务自身的后期维护难度。 请求与响应请求与响应参数是前后端开发人员对接的重要关注点，如果后端 API 不能向前端（甚至是自己）清晰的传达我接收什么，我返回什么的问题，那么对于双方来说，这都是一种灾难。 通用的 ApiResult1234567891011121314151617181920212223242526@Data@AllArgsConstructor@NoArgsConstructorpublic class ApiResult<T> implements Serializable { private static final long serialVersionUID = 2747440445733983051L; /** * 状态 */ private Integer status; /** * 信息 */ private String msg; /** * 响应数据 */ private ...

Spring 项目默认是使用.properties文件作为配置文件的，但是我们习惯上会更多的使用.yml文件，因为其可以体现出配置项的树形结构，可读性较强。 配置文件乱象一般在配置数据源、端口号、服务名称这些配置时并不会出现黄色警告，但是一些自定义的配置项则会出现一片黄色的骇人景象。 虽然有警告，但是这并不是致命错误，因为你仍然可以正常的使用 @Value("${test.a}") 来取值，但是作为有代码洁癖的人，这不能忍！而且 @Value 这种方式很容易因大意导致名称不一致，进而引起无法取值。 主角登场我们先去没有警告的配置项 spring.datasource.url 代码内部，看看是怎么写的，能不能找点蛛丝马迹。 123456789101112131415@ConfigurationProperties( prefix = "spring.datasource")public class DataSourceProperties implements BeanClassLoaderAware, Initial ...

从 Java 8 开始，便拥有了函数式编程的能力。这个能力通俗来讲，就是可以把一个方法实现（也可简单的理解为代码片段）作为参数进行传递，并在适当的时候执行。 Java 有内置的一些类或工具就使用到这个特性，例如整理集合时所使用的stream() 其实在真实的项目开发中，使用这个特性的人并不多。然而在一次偶然的开发过程中，让我深刻理解到这个特性的重要程度，以及它能为代码结构带来多大的优化空间。 为什么要使用它？抛出问题我们来看一个代码场景，现在有一个Procedure类，如下 1234567891011public class Procedure { public static Integer test1(Integer t) { return t + 1; } public static Integer test2(Integer t) { return t + 2; } public static Integer test3(Integer t) { r ...

不知道为什么，最近听到许多反对使用Lombok的声音，说什么影响代码可读性，具有侵入性。（弱弱的问一句，Entity要什么可读性？）这是我从上学的时候认识Lombok以来，第一次听到这样的声音。 在我看来，Lombok大大提高了开发效率。举个栗子，在我最近工作所开发的ERP系统中，由于行业的特殊性，一张表动辄七八十个字段，难道你会为Entity一个一个的去写set和get方法？或者说使用一些工具去生成？反正我打死都不会干的，毕竟人类只有越来越“懒”，才会想尽一切办法去提高生产力。 这篇文章暂且不谈Lombok的优劣，最近我在爬帖子时发现了一个注解，可以优雅的在 Spring 项目中进行 Bean 注入：@RequiredArgsConstructor，这个注解则由Lombok提供。从这个单词来理解，大致就是，必须的参数构造器，那么这个注解又是怎么和Bean注入扯上关系的？向下看。 Bean注入乱象Spring提供了三种注入模式，一种是属性注入(Filed injection)，一种是通过setter方法，一种是构造器注入。就目前情况来看，许多的项目看起来应该是这样的： 123456 ...