前言 最近面了好几家量化、FinTech后端岗位，发现有一道实操题出现频率特别高： “如果给你原始Tick数据，要在服务端聚合成1分钟K线，你会怎么实现？会考虑哪些问题？” 很多人第一反应就是：简单啊，按分钟group by，算开高低收、累加成交量就完事。 但这道题 根本不是考你会不会算OHLCV 。面试官真正想看的，是你有没有做过真实行情流，知不知道线上各种边界异常，能不能把数据质量、乱序、重复、数据闭环这些工程细节讲清楚。 我第一次被问到这道题的时候，一开始也只答了基础聚合逻辑，被面试官不断追问“线上会出什么问题？”“报文乱序怎么办？”“断线重连重复数据怎么处理？”，才意识到这里面藏了非常多考点。 今天结合我自己项目踩坑+面试复盘，用聊天的口吻把这道面试题完整梳理一遍，也说说面试回答时，哪些点是基础分，哪些是加分项。 面试官：拿到A股 API的Tick，如何生成1分钟K线？你会考虑哪些问题？ 我的初级版本回答（只能拿到基础分，容易被追问问住） 最开始我理解就是做数据聚合。拿到每一笔Tick，根据成交时间分到对应的自然分钟桶。同一...

最近面试后端和量化相关岗位，被问到一个非常贴合实际项目的问题： 用WebSocket做美股实时行情推送，如果连接断开，如何实现订阅自动恢复？ 一开始我以为无非就是写个断线重连就搞定了，仔细梳理之后才发现这里藏着一个很容易踩的坑，也是面试官很喜欢追问的点，今天简单跟大家分享一下我的理解。 很多同学第一反应：断了就重建连接，写个循环捕获异常，休眠几秒再重连。 但这里有个核心陷阱： 重连成功，不等于订阅自动恢复。 WebSocket长连接断开之后，程序进程可能还在正常运行，不会崩溃报错，属于静默故障。就算你把网络通道重新连上，如果不重新发送订阅指令，服务端不会继续推送股票行情。表面看连接状态一切正常，实际上已经收不到tick数据。放到真实业务中，数据出现缺口，回测、策略计算都会出问题。 所以完整的处理逻辑不能只做重连，整套流程如下： 1. 持续监控WebSocket连接的健康状态； 2. 检测到断开异常，触发连接重建； 3. 读取提前保存的订阅参数，例如股票代码、数据类型，重新发起订阅请求； 4. 恢复行情接收，继续执行业务处理。 这里要注意，订阅参数一定要保存。如...

在 Java 编程语言中，关键字是具有特殊含义的保留字，它们用于表示语言中的特定功能和操作。 了解和正确使用这些关键字对于编写高效、可靠的 Java 程序至关重要。 今天通过这篇文章，我们一起来了解一下相关的关键字以及含义。 一、关键字汇总 二、访问控制 ✓表示可以访问，x表示不能访问 2.1、private（私有化） private 关键字是访问控制修饰符，可以应用于内部类、方法或类的变量字段。只能在声明 private（内部）类、方法或字段的类中引用这些类、方法或字段。在类的外部或者对于子类而言，它们是不可见的。 2.2、default（缺省） default：关键字是可以应用于类、方法或类的变量字段的访问控制修饰符。当没有指定类的访问权限的时...

虽然Java程序员大部分工作都是 CRUD ，但是工作中常用的中间件必须和Spring集成，如果不知道Spring的原理，很难理解这些中间件和框架的原理。 一张长图透彻解释 Spring启动顺序 Timeout重构 (2).jpg 测试对Spring启动原理的理解程度 我举个例子，测试一下，你对Spring启动原理的理解程度。 1. Rpc框架和Spring的集成问题。Rpc框架何时注册暴露服务，在哪个Spring扩展点注册呢？init-method 中行不行？ 2. MQ 消费组和Spring的集成问题。MQ消费者何时开始消费，在哪个Spring扩展点”注册“自己？init-method 中行不行？ 3. SpringBoot 集成Tomcat问题。如果出现已开启Http流量，Spring还未启动完成，怎么办？Tomcat何时开启端口，对外服务？ SpringBoot项目常见的流量入口无外乎 Rpc、Http、MQ ...

Spring 事务传播机制是指，包含多个事务的方法在相互调用时，事务是如何在这些方法间传播的。 既然是“事务传播”，所以事务的数量应该在两个或两个以上，Spring 事务传播机制的诞生是为了规定多个事务在传播过程中的行为的。比如方法 A 开启了事务，而在执行过程中又调用了开启事务的 B 方法，那么 B 方法的事务是应该加入到 A 事务当中呢？还是两个事务相互执行互不影响，又或者是将 B 事务嵌套到 A 事务中执行呢？所以这个时候就需要一个机制来规定和约束这两个事务的行为，这就是 Spring 事务传播机制所解决的问题。 Spring 事务传播机制有哪些？ Spring 事务传播机制可使用 @Transactional(propagation=Propagation.REQUIRED) 来定义，Spring 事务传播机制的级别包含以下 7 种： 1. Propagation.REQUIRED：默认的事务传播级别，它表示如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。 2. Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果...

背景 公司有个渠道系统，专门对接三方渠道使用，没有什么业务逻辑，主要是转换报文和参数校验之类的工作，起着一个承上启下的作用。 最近在优化接口的响应时间，优化了代码之后，但是时间还是达不到要求；有一个诡异的100ms左右的耗时问题，在接口中打印了请求处理时间后，和调用方的响应时间还有差了100ms左右。比如程序里记录150ms，但是调用方等待时间却为250ms左右。 下面记录下当时详细的定位&解决流程（其实解决很简单，关键在于怎么定位并找到解决问题的方法） 定位过程 分析代码 渠道系统是一个常见的spring-boot web工程，使用了集成的tomcat。分析了代码之后，发现并没有特殊的地方，没有特殊的过滤器或者拦截器，所以初步排除是业务代码问题 分析调用流程 出现这个问题之后，首先确认了下接口的调用流程。由于是内部测试，所以调用流程较少。 Nginx -反向代理  渠道系统 公司是云服务器，网络走的也是云的内网。由于不明确问题的原因，所以用排除法，首先确认服务器网络是否有问题。 先确认发送端到 Nginx Host

虚拟线程（Virtual Thread）也称协程或纤程，是一种轻量级的线程实现，与传统的线程以及操作系统级别的线程（也称为平台线程）相比，它的创建开销更小、资源利用率更高，是 Java 并发编程领域的一项重要创新。 PS：虚拟线程正式发布于 Java 长期支持版（Long Term Suort，LTS）Java 21（也就是 JDK 21）。 虚拟线程是一种在 Java 虚拟机（JVM）层面实现的逻辑线程，不直接和操作系统的物理线程一一对应，因此它可以减少上下文切换所带来的性能开销。 操作系统线程、普通线程（Java 线程）和虚拟线程的关系如下： 1.虚拟线程使用 虚拟线程的创建有以下 4 种方式： 1. Thread.startVirtualThread(Runnable task) 2. Thread.ofVirtual().unstarted(Runnable task) 3. Thread.ofVirtual().fa...

高并发系统有三大特征：限流、缓存和熔断，所以限流已经成为当下系统开发中必备的功能了。那么，什么是限流？如何实现限流？使用 Redis 能不能实现限流？接下来我们一起来看。 1.什么是限流？ 限流是指在各种应用场景中，通过技术和策略手段对数据流量、请求频率或资源消耗进行有计划的限制，以避免系统负载过高、性能下降甚至崩溃的情况发生。限流的目标在于维护系统的稳定性和可用性，并确保服务质量。 使用限流有以下几个好处： 1. 保护系统稳定性 ：过多的并发请求可能导致服务器内存耗尽、CPU 使用率饱和，从而引发系统响应慢、无法正常服务的问题。 2. 防止资源滥用 ：确保有限的服务资源被合理公平地分配给所有用户，防止个别用户或恶意程序过度消耗资源。 3. 优化用户体验 ：对于网站和应用程序而言，如果任由高并发导致响应速度变慢，会影响所有用户的正常使用体验。 4. 保障安全 ：在网络层面，限流有助于防范 DoS/DDoS 攻击，降低系统遭受恶意攻击的风险。 5. 运维成本控制 ：合理的限流措施可以帮助企业减少不必要的硬件投入，节省运营成本。 ...

前言 Spring 官方已不推荐使用 Autowired 字段/属性注入 bean，一些大公司的新项目也明令禁止使用了。 说明 最近公司升级框架，由原来的 spring framework 3.0 升级到 5.0，然后写代码的时候突然发现 idea 在属性注入的 @Autowired 注解上给出警告提示，就像下面这样的，也是挺懵逼的，毕竟这么写也很多年了。 ❝Field injection is not recommended ❞ 查阅了相关文档了解了一下，原来这个提示是 spring framework 4.0 以后开始出现的，spring 4.0 开始就不推荐使用属性注入，改为推荐构造器注入和 setter 注入。 下面将展示了 spring 框架可以使用的不同类型的依赖注入，以及每种依赖注入的适用情况。 依赖注入的类型 尽管针对 spring framework 5.1.3 的文档只定...

前言 如何从整体角度，去设计一个秒杀系统。秒杀系统主要有这几个特征： 瞬时间的流量特别高。过了秒杀的时间，流量就会瞬时结束 大批量用户同时请求极少数商品 在秒杀时间前，可能会有很多请求过来。比如在11点抢票开始，10点59分你可能会提前去刷新页面请求。 所以特意写篇文章给大家说说。秒杀系统，应该满足哪些方面： 1. 满足高并发，快速响应 秒杀系统的瞬时流量特别大，为了防止系统被打垮了，一般要 做压测 。测清楚你的系统支撑的最大并发是多少，确定系统的瓶颈点，让自己心里有底，最好预防措施。 压测完要分析整个调用链路，性能可能出现问题是网络层（如带宽）、Nginx层、服务层、还是数据路缓存等中间件等等。 要快速响应，前期还可以做一些优化。比如 页面资源静态化、缓存热数据预加载、 CDN加速 等等。 2. 防止超卖 做秒杀系统，最主要就是防止超卖问题。所以是要 加 分布式锁 ...