最近在面试量化开发、策略研究相关岗位，发现有一道实操高频题几乎每家都会深挖： 做外汇量化时，如何通过 API 获取实时行情和分钟级历史数据？多品种行情接口混乱该怎么统一治理？ 一开始我以为这就是简单调接口、拿数据，随便讲讲就行。真正聊下去才发现，面试官根本不关心你会不会调用 API，重点考察你有没有真实落地经验、踩过哪些坑、懂不懂工程标准化和回测严谨性。 这里整理一套我面试时完整口述的回答逻辑，通俗易懂、非常贴合面试官想听的实战思路。 一、先讲核心认知：外汇和股票完全不一样 我回答的第一句话，会先铺垫市场底层差异，拉开和新手的差距： 外汇没有中心化交易所，报价全部来自各大做市商和流动性提供商。同一个货币对，不同数据源的报价、点位会存在细微偏差。 这也是为什么很多人回测曲线很漂亮，实盘却完全拉胯，根本原因就是底层数据不标准、接口不统一。 二、实时行情：为什么不推荐 HTTP 轮询？ 面试官大概率会问：你实时行情怎么拿？为什么不用普通轮询？ 我的回答逻辑很简单，分两段讲痛点+最优解： 首先，HTTP 轮询只适合 Demo 测试，完全不适合外汇 7 2...

之前去面量化开发岗位，面试官抛了一个很经典的问题：“你有没有遇到过策略回测表现很漂亮，但上实盘之后效果完全不一样？说说你的理解和实际处理方式。” 这道题看着简单，很多人上来就讲过拟合、参数优化这些理论。我当时直接拿自己做美股日内策略踩过的真实经历当案例来讲，感觉实实在在的项目经历，比空谈概念更能打动面试官。 我之前自己做项目，写过一套美股日内策略。最开始图省事，直接拿分钟K线跑回测，回测收益看着相当亮眼。可等我把策略放到实盘环境一跑，问题直接暴露出来：滑点严重偏离预期，实际成交价格和回测模拟结果差距巨大。 我当时反复排查策略逻辑，来回调整各种参数，折腾好几天，始终找不到代码上的bug。后来才恍然大悟，根源其实出在 行情数据的颗粒度上面 。 分钟K线属于聚合生成的数据，会把盘中大量的真实成交压缩成一根K线。盘中那些转瞬即逝的价格波动、决定滑点的逐笔成交细节，全部在聚合过程丢失了。依靠这种数据做回测，很容易得到过于乐观的结果。想要还原真实市场，就必须使用逐笔Tick数据开展回测。 面试官接着追问，那挑选Tick数据源的时候，你会重点评估哪些点？ 我就结合自己调研的过程...

前言 最近面了好几家量化、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. 运维成本控制 ：合理的限流措施可以帮助企业减少不必要的硬件投入，节省运营成本。 ...