最近几天渐渐悟出来一个道理，做技术没有出路。

我在想如果哪天我失业了，没有公司要我，以我现在的经验和能力，我该怎么办？

结果是我什么都干不了，我的经验和能力必须依靠公司才有价值，我在社会上独立生存，跟普通人比，没有任何优势。

所以我觉得做技术，尤其是走技术专家路线，根本没有出路，路越走越窄，最后把自己绑死在公司。

这段时间买了不少课，学了很多思路，打开了视野，也非常认真的思考，找身边厉害的人聊，写出这篇文章，希望可以供你参考。

培养赚钱的能力

赚钱的思维：发现需求，满足需求，推广流量。

普通人能赚到大钱的地方，都是很 low 的。我说几个自己身边的和听过的案例。

有的爸妈上班孩子放学没人接，有人开个自习室把孩子从学校接过来，每个孩子 700 块，一个月赚几万块。

前几年搞视频号，有一哥们做了个租房合同的带货视频爆了，赚了 20 多万。

老婆表姐搞外贸，老早没上班自己开了公司，具体不知道赚了多少钱，但有倒腾鞋子袜子的案例，一年 100 个没有问题。

还有各种卖包装盒、打包盒、塑料袋、花生瓜子、酱菜、小板凳的案例，包括我今天下楼看了下小区周边，我们这条街在金融港正对面，不可否认有些店没过多久倒闭了，但还有些店，招牌已经破的不行还开着在，包括各种餐饮店、收废品、五金、中老年活动中心、中医推拿针灸按摩、宠物店。他们肯定是赚到了钱，而且事情本身没什么门槛。

这些事给我刺激够大的，世界上赚钱的方式不只打工，从大学出来是第一次进入社会，跳出工作是第二次进入社会。

把他们抽象一下，都是发现了某个需求，然后找到了解决方案，再把方案推广让更多人知道。

解决方案各种各样，可以是做个产品（美团、饿了么各种 App 都是），也可以是简单的对接下资源，找个服装厂、鞋厂，甚至直接在 PDD 上代发货，这也是为什么我觉得搞技术没出路原因，解决方案面太窄，资产太重，一个人干不起来。

对我未来有什么启发呢？我分别说说。

发现需求

这个真的难，没抽象出方法论，因为这东西是别人赚钱的底裤，没人会分享，我要有正在赚钱的路子我也不可能说出来，上面说出来的都是过时的。

可行的方案是保持好奇，保持观察，多了解案例，自己多领悟。接地气，多关注衣食住行、吃喝拉撒方面的。

有机会我准备去广州、福建那里有各种代工厂、工业园，找人聊聊积累一些下游资源，多和身边的人聊天换取信息，多认识这个世界，积累各种各样的资源。

满足需求

在职场上，可以往产品经理方向发展。能锻炼自己产品思维，对自己未来创业是有帮助的。

另外搞产品也需要一定的沟通能力，这也能对接上创业时的销售能力。不管搞什么，这两项能力都是必要的。

我在做开发前做过几年销售，而且后期写的一些项目，我也承担了部分产品的职责，往这个方向转，对我来说没有问题，尤其是偏技术的产品，更是信手拈来。

推广流量

往投流方向转，也是可行的。要想赚钱，就得离钱近，投流是离钱最近的。

我了解投流的大致逻辑，ROI 怎么跑正，每个环节数据怎么排查，做增量的大致方向。

这个方面我缺少具体可能遇到的细节经验，或者行业的一些潜规则，平台的规则等。

但其实问题不大，流量方法不是公开的，如果公开的大家都一窝蜂上去投，就会把价格越拉越高，直到超过成本。

重点是如何用更低的价格买到流量，这里面可能有很多野路子、钻空子、薅羊毛等。

而且我之前做视频号的时候，也做过各个赛道，累计有上千万播放和几万粉丝，也算有点经验。

所以往投放方向转，我也有信心做好。

技术本行

再说到技术老本行，我不会去钻研高精尖的东西，就各种大厂面试题里的情况，实话实说工作了 7 年，面试题里面的场景一个都没有遇到，就像知乎上问：什么时候用 ArrayList 什么时候用 LinkList？答曰：工作中用 ArrayList，面试时用 LinkList。

技术上精通基本数据类型、Java 核心、MySQL、分库分表、SpringBoot、Spring Cloud相关、Redis、Kafka、Idea 熟练度等，就差不多了。

重要的还有项目经验、架构设计、业务场景处理那些。我会把这些做成视频发到 B 站上，一方面可以提升自己的技能熟练度，另一方面也能为自己攒点影响力。

然后把精力放在横向扩展上，比如关注 GitHub 各种搭建完就能用的开源项目，思考他们可以用在哪些场景，满足哪些需求。

总之，不管是未来做什么，我的目标是提升自己的赚钱能力，也留意观察、抓住生活中机会。

加油，共勉。

在这个人人都希望成为**“别人家的孩子”的社会，职场不再仅仅是能力和经验的比拼，越来越多的成功与否取决于你有多会“装”**。

_“Fake It Till You Make It”_______假装自己是个成功人士，直到你的真成功；

这句话就是你在职场打拼的**“生存法则”。但你得明白，不只是说你穿上西装，喝着美式，走进办公室时“演”得像个大老板那么简单。更深层的含义是，如何通过一系列的“装腔作势”提升你的职场竞争力，赢得机会，获得认可，最终实现“真的成功”**。

那么，如何才能通过假装来达成最终的成功呢？接下来，就让我带你走进这个充满**“假装有”与“真成功”**的奇妙世界。

从“低调内敛”到“虚伪高调”：职场的伪装艺术

在职场这个丛林里，初入职场的你，可能会觉得**“踏实肯干、低调内敛”才是好员工的标配。结果你会发现，老板们并不总是青睐于那些“只会做事不吭声”**的人。你低调的态度可能换来的是同事们的忽视，而领导眼中那种总是抢着发言、处处表现自信的人，反而成了职场的宠儿。

这时候，“Fake It Till You Make It”的原则就该派上用场了——先装出自信来。你可以从微笑开始，站直背部，记住要有眼神交流，在开会时积极举手发言，不管发言内容有多无聊。假装自己充满自信，直到你真的有了自信。对，你没有听错，职场上并不是能力最强的人会被选中，而是最懂得“装”的人更容易获得机会。

这种自信的“伪装”并不意味着你要抬高姿态、目中无人，而是要学会在恰当的时机表现自己的优点，让领导和同事看到你是一个值得信赖且能力超群的员工。当你开始给自己打上“成功”的标签时，实际上，你在塑造的，是一个成功的未来——因为别人总是愿意把机会给予那些看起来已经成功的人。

学会“装”——从外部形象到内心成长

_如果说职场上有一种“游戏规则”是“假装自己很牛逼，直到真的牛逼”，那么“装”就是你进入游戏的第一步。_外在的“装”不只是表面功夫，它会逐渐影响你的行为、思维方式，甚至改变你的人际互动模式。

例如，你会发现那些在职场中游刃有余的人，往往外表非常得体。你想要升职加薪，首先要让自己看起来像个管理者，而不仅仅是一个“执行者”。这不意味着你要立即换掉你的整个衣柜，但至少可以从一些小细节入手，比如穿一件干净的白衬衫、戴一副时尚眼镜、换一个有品位的皮包。

此外，职场上，你还得学会用“术语”。在会议中，不妨适时地插入一些行业内的术语或关键词，如“优化流程”、“高效协作”、“数据驱动”，即使你并不完全理解这些术语的含义，也要先把它们抛出来，听起来有点“术业有专攻”的味道，这样能让你在别人面前显得非常专业和有见地。

这种外部“伪装”会潜移默化地影响你的行为方式，甚至改变你在职场中的定位。因为，当你开始装作一个“大咖”时，你会越来越觉得自己“真的”是那个大咖，进而逐渐产生内心的自信，而这种自信，会成为你真正成功的驱动力。

职场社交：假装你是社交达人

在职场中，社交能力也是一个不可忽视的重要技能。其实，很多时候，一个人能否在职场上迅速上升，除了能力，往往还取决于他的“朋友圈”。如果你总是低调、害羞，甚至害怕与别人交往，那么即使你有再高的能力，也可能会因为缺乏人脉而错失机会。

_这时，学会“假装自己是个社交达人”显得尤为重要。_你不必真的变成一个性格外向、八面玲珑的社交专家，但你可以通过一些技巧来“伪装”自己，逐渐融入到这个职场网络中。比如，在午休时主动邀请同事一起吃饭，或者偶尔给领导发个微信，问问工作上的问题，哪怕只是闲聊几句，都会让你在人际关系上“装腔作势”，形成一个积极的职场形象。

当你开始活跃在社交场合，你就会发现自己变得越来越有话题，越来越能够与不同的人建立联系，这样不仅能增加你获得职位晋升的机会，还能获得更多的资源和支持。而这些人脉，最终会成为你真正成功的助力。

逆袭法则：从“假装做事”到“真正做事”

“Fake It Till You Make It”的过程，从来不仅仅是“装”而已。它的更深层次的意义在于，假装自己的能力，直到你能够真正实现这些能力。而这个过程中，最重要的一步，就是通过“装”来激发行动。

举个例子，假设你刚刚进入公司，作为一个新人，你可能并不具备直接承担大项目的能力，但你可以通过装作“已经准备好接受挑战”的姿态，主动请求领导给你一些重要的任务。在这些任务中，虽然你可能会遇到困难和挑战，但你会发现，通过不断学习、努力和实践，你其实能够逐渐掌握这些技能，最终成为一个真正能做事的人。

这种转变并不是一蹴而就的，而是一个渐进的过程。你通过“假装”自己可以承担更大责任，最后真的承担了这些责任，并且做得越来越好。当你从外部的“假装”进入内心的“真实”时，你的职场竞争力将大大增强。

摆脱“装腔”困境，做最真实的自己

尽管“Fake It Till You Make It”是职场上一个行之有效的策略，但它并非万能。长期依赖“装腔作势”可能会导致身份迷失，甚至产生情感上的空虚感。因此，在职场的“装腔”过程中，最终的目标应当是通过提升自己的能力，真正“做”出成绩，摆脱对表象的过度依赖。

在你“装”成一个自信、成功的职场人之后，不妨逐渐开始寻找自己内心的真实想法，明确自己的职业目标，做出真正符合自己价值观的选择。这个过程中，外在的伪装和内心的成长应该逐步融合，最终让你在职场上不仅仅是一个“假装成功”的人，而是一个“真正成功”的人。

结语：职场的“伪装”是为了更好地成长

“Fake It Till You Make It”这句话，听起来可能有些浮夸，甚至让人觉得不太真实，但它实际上是一种职场中的生存策略。通过外在的“装腔”，你可以提升自信，获得机会，推动自己朝着真正的成功迈进。但最终，只有当你通过不断学习和积累，真正掌握了自己的职业技能，你才会发现，那些“假装”的外衣早已不再需要。

职场就是这样一个既充满竞争又充满机遇的地方。在这片“充满假象”的舞台上，假装自己是一位大咖，并不等于永远是个“假大咖”，而是通过一段时间的“装腔”，让自己在不断进步中成为那个真正的“大咖”。

介绍

最近上了一个新项目，考虑到一个问题，在高并发场景下，我们无法控制前端的请求频率和次数，这就可能导致服务器压力过大，响应速度变慢，甚至引发系统崩溃等严重问题。为了解决这些问题，我们需要在后端实现一些机制，如接口限流、防重复提交和接口防抖，而这些是保证接口安全、稳定提供服务，以及防止错误数据 和 脏数据产生的重要手段。

而AOP适合在在不改变业务代码的情况下，灵活地添加各种横切关注点，实现一些通用公共的业务场景，例如日志记录、事务管理、安全检查、性能监控、缓存管理、限流、防重复提交等功能。这样不仅提高了代码的可维护性，还使得业务逻辑更加清晰专注，关于AOP不理解的可以看这篇文章。

接口限流

接口限流是一种控制访问频率的技术，通过限制在一定时间内允许的最大请求数来保护系统免受过载。限流可以在应用的多个层面实现，比如在网关层、应用层甚至数据库层。常用的限流算法有漏桶算法（Leaky Bucket）、令牌桶算法（Token Bucket）等。限流不仅可以防止系统过载，还可以防止恶意用户的请求攻击。

限流框架大概有

0. spring cloud gateway集成redis限流，但属于网关层限流
1. 阿里Sentinel，功能强大、带监控平台
2. srping cloud hystrix，属于接口层限流，提供线程池与信号量两种方式
3. 其他：redisson、redis手撸代码

本文主要是通过 Redisson 的分布式计数来实现的 固定窗口 模式的限流，也可以通过 Redisson 分布式限流方案(令牌桶)的的方式RRateLimiter。

在高并发场景下，合理地实施接口限流对于保障系统的稳定性和可用性至关重要。

• 自定义接口限流注解类 @AccessLimit

/**

 * 接口限流

 */

@Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.METHOD)

public @interface AccessLimit {



    /**

     * 限制时间窗口间隔长度，默认10秒

     */

    int times() default 10;



    /**

     * 时间单位

     */

    TimeUnit timeUnit() default TimeUnit.SECONDS;



    /**

     * 上述时间窗口内允许的最大请求数量，默认为5次

     */

    int maxCount() default 5;



    /**

     * redis key 的前缀

     */

    String preKey();



    /**

     * 提示语

     */

    String msg() default "服务请求达到最大限制，请求被拒绝！";

}

• 利用AOP实现接口限流

/**

 * 通过AOP实现接口限流

 */

@Component

@Aspect

@Slf4j

@RequiredArgsConstructor

public class AccessLimitAspect {



    private static final String ACCESS_LIMIT_LOCK_KEY = "ACCESS_LIMIT_LOCK_KEY";



    private final RedissonClient redissonClient;



    @Around("@annotation(accessLimit)")

    public Object around(ProceedingJoinPoint point, AccessLimit accessLimit) throws Throwable {



        String prefix = accessLimit.preKey();

        String key = generateRedisKey(point, prefix);



        //限制窗口时间

        int time = accessLimit.times();

        //获取注解中的令牌数

        int maxCount = accessLimit.maxCount();

        //获取注解中的时间单位

        TimeUnit timeUnit = accessLimit.timeUnit();



        //分布式计数器

        RAtomicLong atomicLong = redissonClient.getAtomicLong(key);



        if (!atomicLong.isExists() || atomicLong.remainTimeToLive() <= 0) {

            atomicLong.set(0);

            atomicLong.expire(time, timeUnit);

        }



        long count = atomicLong.incrementAndGet();

        ;

        if (count > maxCount) {

            throw new LimitException(accessLimit.msg());

        }



        // 继续执行目标方法

        return point.proceed();

    }



    public String generateRedisKey(ProceedingJoinPoint point, String prefix) {

        //获取方法签名

        MethodSignature methodSignature = (MethodSignature) point.getSignature();

        //获取方法

        Method method = methodSignature.getMethod();

        //获取全类名

        String className = method.getDeclaringClass().getName();



        // 构建Redis中的key，加入类名、方法名以区分不同接口的限制

        return String.format("%s:%s:%s", ACCESS_LIMIT_LOCK_KEY, prefix, DigestUtil.md5Hex(String.format("%s-%s", className, method)));

    }

}

• 调用示例实现

@GetMapping("/getUser")

@AccessLimit(times = 10, timeUnit = TimeUnit.SECONDS, maxCount = 5, preKey = "getUser", msg = "服务请求达到最大限制，请求被拒绝！")

public Result getUser() {

    return Result.success("成功访问");

}

防重复提交

在一些业务场景中，重复提交同一个请求可能会导致数据的不一致，甚至严重影响业务逻辑的正确性。例如，在提交订单的场景中，重复提交可能会导致用户被多次扣款。为了避免这种情况，可以使用防重复提交技术，这对于保护数据一致性、避免资源浪费非常重要

• 自定义接口防重注解类 @RepeatSubmit

/**

* 自定义接口防重注解类

*/

@Documented

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface RepeatSubmit {

    /**

     * 定义了两种防止重复提交的方式，PARAM 表示基于方法参数来防止重复，TOKEN 则可能涉及生成和验证token的机制

     */

    enum Type { PARAM, TOKEN }

    /**

     * 设置默认的防重提交方式为基于方法参数。开发者可以不指定此参数，使用默认值。

     * @return Type

     */

    Type limitType() default Type.PARAM;

 

    /**

     * 允许设置加锁的过期时间，默认为5秒。这意味着在第一次请求之后的5秒内，相同的请求将被视为重复并被阻止

     */

    long lockTime() default 5;

    

    //提供了一个可选的服务ID参数，通过token时用作KEY计算

    String serviceId() default ""; 

    

    /**

     * 提示语

     */

    String msg() default "请求重复提交！";

}

• 利用AOP实现接口防重处理

/**

 * 利用AOP实现接口防重处理

 */

@Aspect

@Slf4j

@RequiredArgsConstructor

@Component

public class RepeatSubmitAspect {



    private final String REPEAT_SUBMIT_LOCK_KEY_PARAM = "REPEAT_SUBMIT_LOCK_KEY_PARAM";



    private final String REPEAT_SUBMIT_LOCK_KEY_TOKEN = "REPEAT_SUBMIT_LOCK_KEY_TOKEN";



    private final RedissonClient redissonClient;



    private final RedisRepository redisRepository;



    @Pointcut("@annotation(repeatSubmit)")

    public void pointCutNoRepeatSubmit(RepeatSubmit repeatSubmit) {



    }



    /**

     * 环绕通知, 围绕着方法执行

     * 两种方式

     * 方式一：加锁 固定时间内不能重复提交

     * 方式二：先请求获取token，再删除token,删除成功则是第一次提交

     */

    @Around("pointCutNoRepeatSubmit(repeatSubmit)")

    public Object around(ProceedingJoinPoint joinPoint, RepeatSubmit repeatSubmit) throws Throwable {

        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();



        //用于记录成功或者失败

        boolean res = false;



        //获取防重提交类型

        String type = repeatSubmit.limitType().name();

        if (type.equalsIgnoreCase(RepeatSubmit.Type.PARAM.name())) {

            //方式一，参数形式防重提交

            //通过 redissonClient 获取分布式锁，基于IP地址、类名、方法名生成唯一key

            String ipAddr = IPUtil.getIpAddr(request);

            String preKey = repeatSubmit.preKey();

            String key = generateTokenRedisKey(joinPoint, ipAddr, preKey);



            //获取注解中的锁时间

            long lockTime = repeatSubmit.lockTime();

            //获取注解中的时间单位

            TimeUnit timeUnit = repeatSubmit.timeUnit();



            //使用 tryLock 尝试获取锁，如果无法获取（即锁已被其他请求持有），则认为是重复提交，直接返回null

            RLock lock = redissonClient.getLock(key);

            //锁自动过期时间为 lockTime 秒，确保即使程序异常也不会永久锁定资源，尝试加锁，最多等待0秒，上锁以后 lockTime 秒自动解锁 [lockTime默认为5s, 可以自定义]

            res = lock.tryLock(0, lockTime, timeUnit);



        } else {

            //方式二，令牌形式防重提交

            //从请求头中获取 request-token，如果不存在，则抛出异常

            String requestToken = request.getHeader("request-token");

            if (StringUtils.isBlank(requestToken)) {

                throw new LimitException("请求未包含令牌");

            }

            //使用 request-token 和 serviceId 构造Redis的key，尝试从Redis中删除这个键。如果删除成功，说明是首次提交；否则认为是重复提交

            String key = String.format("%s:%s:%s", REPEAT_SUBMIT_LOCK_KEY_TOKEN, repeatSubmit.serviceId(), requestToken);

            res = redisRepository.del(key);

        }



        if (!res) {

            log.error("请求重复提交");

            throw new LimitException(repeatSubmit.msg());

        }



        return joinPoint.proceed();

    }



    private String generateTokenRedisKey(ProceedingJoinPoint joinPoint, String ipAddr, String preKey) {

        //根据ip地址、用户id、类名方法名、生成唯一的key

        MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();

        Method method = methodSignature.getMethod();

        String className = method.getDeclaringClass().getName();

        String userId = "seven";

        return String.format("%s:%s:%s", REPEAT_SUBMIT_LOCK_KEY_PARAM, preKey, DigestUtil.md5Hex(String.format("%s-%s-%s-%s", ipAddr, className, method, userId)));

    }

}

• 调用示例

@PostMapping("/saveUser")

@RepeatSubmit(limitType = RepeatSubmit.Type.PARAM,lockTime = 5,timeUnit = TimeUnit.SECONDS,preKey = "saveUser",msg = "请求重复提交")

public Result saveUser() {

    return Result.success("成功保存");

}

接口防抖

接口防抖是一种优化用户操作体验的技术，主要用于减少短时间内高频率触发的操作。例如，当用户快速点击按钮时，我们可以通过防抖机制，只处理最后一次触发的操作，而忽略前面短时间内的多次操作。防抖技术常用于输入框文本变化事件、按钮点击事件等场景，以提高系统的性能和用户体验。

后端接口防抖处理主要是为了避免在短时间内接收到大量相同的请求，特别是由于前端操作（如快速点击按钮）、网络重试或异常情况导致的重复请求。后端接口防抖通常涉及记录最近的请求信息，并在特定时间窗口内拒绝处理相同或相似的请求。

• 定义自定义注解 @AntiShake

// 该注解只能用于方法

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)// 运行时保留，这样才能在AOP中被检测到

public @interface AntiShake {



    String preKey() default "";



    // 默认防抖时间1秒

    long value() default 1000L;



    TimeUnit timeUnit() default TimeUnit.MILLISECONDS;

}

• 实现AOP切面处理防抖

@Aspect // 标记为切面类

@Component // 让Spring管理这个Bean

@RequiredArgsConstructor // 通过构造方法注入依赖

public class AntiShakeAspect {



    private final String ANTI_SHAKE_LOCK_KEY = "ANTI_SHAKE_LOCK_KEY";



    private final RedissonClient redissonClient;



    @Around("@annotation(antiShake)") // 拦截所有标记了@AntiShake的方法

    public Object aroundAdvice(ProceedingJoinPoint joinPoint, AntiShake antiShake) throws Throwable {

        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();



        long currentTime = System.currentTimeMillis();



        // 获取方法签名和参数作为 Redis 键

        String ipAddr = IPUtil.getIpAddr(request);

        String key = generateTokenRedisKey(joinPoint, ipAddr, antiShake.preKey());



        RBucket bucket = redissonClient.getBucket(key);

        Long lastTime = bucket.get();



        if (lastTime != null && currentTime - lastTime < antiShake.value()) {

            // 如果距离上次调用时间小于指定的防抖时间，则直接返回，不执行方法

            return null; // 根据业务需要返回特定值

        }



        // 更新 Redis 中的时间戳

        bucket.set(currentTime, antiShake.value(), antiShake.timeUnit());

        return joinPoint.proceed(); // 执行原方法

    }



    private String generateTokenRedisKey(ProceedingJoinPoint joinPoint, String ipAddr, String preKey) {

        //根据ip地址、用户id、类名方法名、生成唯一的key

        MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();

        Method method = methodSignature.getMethod();

        String className = method.getDeclaringClass().getName();

        String userId = "seven";

        return String.format("%s:%s:%s", ANTI_SHAKE_LOCK_KEY, preKey, DigestUtil.md5Hex(String.format("%s-%s-%s-%s", ipAddr, className, method, userId)));

    }

}

• 调用示例代码

@PostMapping("/clickButton")

@AntiShake(value = 1000, timeUnit = TimeUnit.MILLISECONDS, preKey = "clickButton")

public Result clickButton() {

    return Result.success("成功点击按钮");

}

接口防抖整体思路与防重复提交思路类似，防重复提交代码也可重用于接口防抖

关于作者

来自一线程序员Seven的探索与实践，持续学习迭代中~

本文已收录于我的个人博客：http://www.seven97.top

公众号：seven97，欢迎关注~

作者：Seven97
来源：juejin.cn/post/7408859165433364490

一、背景

某天，张三打算操作数据库，删除自己项目的无用数据，但是一不小心数据删多了。被误删的数据，如何恢复呢？本文将介绍相关方法，以及现成的一些工具。

例子：

有一个表

create table person

(

  id   bigint primary key auto_increment comment 'id',

  name varchar(50) comment '名称'

) engine = innodb;

原本是要执行这条SQL语句：

delete from person where id > 500000;

不小心执行了这条SQL语句：

delete from person;

二、解决方案

处理这个问题的解决思路就是，基于binlog找回被删除的数据，将被删除的数据重新插入到数据库。

对于binlog文件来说，实际上保存的是对于数据库的正向操作。比如说，插入数据insert，binlog中保存的也是insert语句；删除数据delete，binlog中保存的也是delete语句。

因此，想要恢复被删除的数据，主要有两种方式：

下面就针对上面的两种方式，进行详细的讲解

1. 通用操作

首先介绍两种方式都需要使用到的一些通用的操作，主要用于设置binlog、找到binlog文件

1.1 确认binlog开启

1.1.1 查询开启状态

首先要保证binlog是开启的，不然数据肯定是没办法恢复回来的。

在MySQL中，可以通过执行以下SQL查询来检查是否已经开启了binlog：

SHOW VARIABLES LIKE 'log_bin';

这个查询将返回一个结果集，其中包含名为log_bin的系统变量的值。如果log_bin的值为ON，则表示binlog已经开启；如果值为OFF，则表示binlog没有开启。

mysql> SHOW VARIABLES LIKE 'log_bin';

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

| Variable_name | Value |

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

| log_bin       | ON    |

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

1 row in set (0.01 sec)

1.1.2 开启binlog

如果发现没有开启，可以通过修改MySQL配置文件（通常是my.cnf或my.ini，Linux下MySQL的配置文件目录一般是/etc/mysql）中的[mysqld]部分来开启binlog。如果在配置文件中找到了类似以下的设置，则表示binlog已经开启：

[mysqld]

log-bin=mysql-bin

server-id=1

1. 修改配置启用了binlog之后，需要重启MySQL服务才能使更改生效


2. mysql-bin表示binlog文件的前缀


3. server-id 设置了MySQL服务器的唯一ID，必须设置ID，否则没办法开启binlog

1.2 binlog模式

刚刚提到，对于delete操作，只有row模式才能找到被删除数据的具体值，因此需要确认开启的binlog模式。

1.2.1 查询binlog模式

要查询MySQL的binlog模式，您可以使用以下SQL命令：

SHOW VARIABLES LIKE 'binlog_format';

这将返回一个结果集，其中包含当前的binlog格式。可能的值有：

• ROW：表示使用行模式（row-based replication），这是推荐的设置，因为它提供了更好的数据一致性。


• STATEMENT：表示使用语句模式（statement-based replication），在这种模式下，可能会丢失一些数据，因为它仅记录执行的SQL语句。


• MIXED：表示混合模式（mixed-based replication），在这种模式下，MySQL会根据需要自动切换行模式和语句模式。

1.2.2 配置binlog模式

可以通过修改MySQL配置文件（通常是my.cnf或my.ini，Linux下MySQL的配置文件目录一般是/etc/mysql）中的[mysqld]部分来修改binlog模式。

在[mysqld]部分下，添加或修改以下行，将binlog_format设置为想要的模式（ROW、STATEMENT或MIXED）：

[mysqld]

binlog_format=ROW

随后重启mysql服务使其生效

1.3 binlog信息查询

通过以下操作，我们可以找到binlog文件

1.3.1 查询当前使用的binlog文件

通过show master status;可以找到当前正在使用的binlog文件

mysql> show master status\G

*************************** 1. row ***************************

             File: mysql-bin.000217

         Position: 668127868

     Binlog_Do_DB: 

 Binlog_Ignore_DB: 

Executed_Gtid_Set: 29dc2bf9-f657-11ee-b369-08c0eb829a3c:1-291852745,

744ca9cd-5f86-11ef-98d6-0c42a131d16f:1-5374311

1 row in set (0.00 sec)

1.3.2 找到所有binlog文件名

show master logs;可以找到所有binlog文件名

mysql> show master logs;

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

| Log_name         | File_size  |

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

| mysql-bin.000200 | 1073818388 |

| mysql-bin.000201 | 1073757563 |

| mysql-bin.000202 | 1074635635 |

| mysql-bin.000203 | 1073801053 |

| mysql-bin.000204 | 1073856643 |

| mysql-bin.000205 | 1073910661 |

| mysql-bin.000206 | 1073742603 |

| mysql-bin.000207 | 1195256434 |

| mysql-bin.000208 | 1085915611 |

| mysql-bin.000209 | 1073990985 |

| mysql-bin.000210 | 1075942323 |

| mysql-bin.000211 | 1074716392 |

| mysql-bin.000212 | 1073763938 |

| mysql-bin.000213 | 1073780482 |

| mysql-bin.000214 | 1074029712 |

| mysql-bin.000215 | 1073832842 |

| mysql-bin.000216 | 1079999184 |

| mysql-bin.000217 |  668173793 |

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

1.3.3 查询binlog保存位置

SHOW VARIABLES LIKE 'log_bin_basename'; 可以找到binlog文件保存的目录位置。比如说/var/lib/mysql/mysql-bin表示目录为/var/lib/mysql/下的以mysql-bin为前缀的文件。

我们通过文件的最后修改时间，可以看出binlog覆盖的时间范围。一般后缀的数字越大，表示越新。

mysql> SHOW VARIABLES LIKE 'log_bin_basename';

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

| Variable_name    | Value                    |

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

| log_bin_basename | /var/lib/mysql/mysql-bin |

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

1 row in set (0.00 sec)

bash-4.2# ls /var/lib/mysql/mysql-bin* -alh

-rw-r----- 1 mysql mysql 1.1G Sep  9 02:28 /var/lib/mysql/mysql-bin.000200

-rw-r----- 1 mysql mysql 1.1G Sep  9 02:32 /var/lib/mysql/mysql-bin.000201

-rw-r----- 1 mysql mysql 1.1G Sep  9 02:39 /var/lib/mysql/mysql-bin.000202

-rw-r----- 1 mysql mysql 1.1G Sep  9 02:45 /var/lib/mysql/mysql-bin.000203

-rw-r----- 1 mysql mysql 1.1G Sep  9 07:52 /var/lib/mysql/mysql-bin.000204

-rw-r----- 1 mysql mysql 1.1G Sep  9 12:10 /var/lib/mysql/mysql-bin.000205

-rw-r----- 1 mysql mysql 1.1G Sep 10 04:40 /var/lib/mysql/mysql-bin.000206

-rw-r----- 1 mysql mysql 1.2G Sep 10 07:00 /var/lib/mysql/mysql-bin.000207

-rw-r----- 1 mysql mysql 1.1G Sep 11 07:54 /var/lib/mysql/mysql-bin.000208

-rw-r----- 1 mysql mysql 1.1G Sep 12 03:03 /var/lib/mysql/mysql-bin.000209

-rw-r--r-- 1 root  root   24M Sep 11 09:06 /var/lib/mysql/mysql-bin.000209.event.log

-rw-r----- 1 mysql mysql 1.1G Sep 12 03:30 /var/lib/mysql/mysql-bin.000210

-rw-r----- 1 mysql mysql 1.1G Sep 12 08:33 /var/lib/mysql/mysql-bin.000211

-rw-r----- 1 mysql mysql 1.1G Sep 12 08:35 /var/lib/mysql/mysql-bin.000212

-rw-r----- 1 mysql mysql 1.1G Sep 12 22:00 /var/lib/mysql/mysql-bin.000213

-rw-r----- 1 mysql mysql 1.1G Sep 13 10:26 /var/lib/mysql/mysql-bin.000214

-rw-r----- 1 mysql mysql 1.1G Sep 13 10:29 /var/lib/mysql/mysql-bin.000215

-rw-r----- 1 mysql mysql 1.1G Sep 14 01:42 /var/lib/mysql/mysql-bin.000216

-rw-r----- 1 mysql mysql 637M Sep 14 06:11 /var/lib/mysql/mysql-bin.000217

-rw-r----- 1 mysql mysql 4.1K Sep 14 01:42 /var/lib/mysql/mysql-bin.index

2. 方案一：找到insert语句，重新插入

需要执行以下几个步骤：

2.1 找到binlog文件

比如说，数据是在9月12日12:00插入的，那么我们看上方的所有binlog文件，可以看出插入语句应该保存在mysql-bin.000213文件中。

2.2 根据时间点解析binlog文件

通过mysqlbinlog将binlog文件解析成可读的sql文件。

mysqlbinlog --base64-output=decode-rows -v --start-datetime="2024-09-12 11:59:00" --stop-datetime="2024-09-12 12:01:00" mysql-bin.000213 > binlog.sql

• --base64-output=decode-rows：将二进制日志中的行事件解码为 SQL 语句。


• -v 或 --verbose：输出详细的事件信息。


• --start-datetime="2024-09-12 11:59:00"：从指定的日期和时间开始读取二进制日志。通过指定时间范围，可以减小解析出来的sql文件，避免太多无用信息使得查询位置比较困难。


• --stop-datetime="2024-09-12 12:01:00"：在指定的日期和时间停止读取二进制日志。


• mysql-bin.000213：要解析的二进制日志文件的路径和名称。


• >：将命令的输出重定向到指定的文件。


• binlog.sql：保存解码后的 SQL 语句的文件名。

2.2.1 statement模式确认binlog位置

我们可以找到insert int0 person values (1, 'first')，并且分别在前后的BEGIN和COMMIT找到position。

BEGIN往前找有一个position at 219，COMMIT往后找有一个position at 445，这就是插入语句的实际binlog范围。

# at 219

#240914 17:14:26 server id 1  end_log_pos 300 CRC32 0xb8159bc1 	Query	thread_id=1267	exec_time=0	error_code=0

SET TIMESTAMP=1726305266/*!*/;

SET @@session.pseudo_thread_id=1267/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1436549120/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C latin1 *//*!*/;

SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 300

#240914 17:14:26 server id 1  end_log_pos 414 CRC32 0xb7e0263b 	Query	thread_id=1267	exec_time=0	error_code=0

use `tests`/*!*/;

SET TIMESTAMP=1726305266/*!*/;

insert int0 person values (1, 'first')

/*!*/;

# at 414

#240914 17:14:26 server id 1  end_log_pos 445 CRC32 0x9345e6ca 	Xid = 30535

COMMIT/*!*/;

# at 445

2.2.2 row模式确认binlog位置

row模式下，与statement模式下的binlog格式有少许差别，但方法是一致的。

我们可以找到以 ###开头的几行，包含INSERT INTO语句。并且分别在前后的BEGIN和COMMIT找到position。

BEGIN往前找有一个position at 219，COMMIT往后找有一个position at 426，这就是插入语句的实际binlog范围。

# at 219

#240914 17:16:36 server id 1  end_log_pos 292 CRC32 0xe9082d52 	Query	thread_id=20	exec_time=0	error_code=0

SET TIMESTAMP=1726305396/*!*/;

SET @@session.pseudo_thread_id=20/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1436549120/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C latin1 *//*!*/;

SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 292

#240914 17:16:36 server id 1  end_log_pos 345 CRC32 0x1832ced4 	Table_map: `tests`.`person` mapped to number 111

# at 345

#240914 17:16:36 server id 1  end_log_pos 395 CRC32 0x32d6a21b 	Write_rows: table id 111 flags: STMT_END_F

### INSERT INTO `tests`.`person`

### SET

###   @1=1

###   @2='first'

# at 395

#240914 17:16:36 server id 1  end_log_pos 426 CRC32 0x07619928 	Xid = 149

COMMIT/*!*/;

# at 426

2.3 根据binlog位置解析binlog文件

上一步，我们已经找到了具体的位置，现在我们可以重新解析binlog文件，指定binlog位置。内容和上方实际上没有太大差异。

mysqlbinlog --start-position=219 --stop-position=426 mysql-bin.000213 > binlog.sql

需要注意的是，这个解析语句，删掉了--base64-output=decode-rows -v 参数。因为这些参数是用于解码binlog的，是让开发人员更方便看到binlog被解析之后的格式。但是对mysql来说是没办法使用的。

2.4 重放数据

解析的这个文件就是一个sql脚本文件，通过往常的方式执行sql脚本即可

mysql -uroot -proot < binlog.sql

或者mysql客户端登陆之后，通过source命令执行

source binlog.sql;

3. 方案二：找到delete语句，生成逆向操作，重新insert

3.1 找到binlog文件

比如说，数据是在9月12日12:00删除的，那么我们看上方的所有binlog文件，可以看出插入语句应该保存在mysql-bin.000213文件中。

3.2 根据时间点解析binlog文件

操作和上方2.2的操作没有差异，我们主要来比较一下statement模式和row模式的差别。我们会发现statement模式下，没办法找到所有被删除的数据的具体数据，而row模式能找到。

3.2.1 statement模式

我们可以看到binlog只保存了一句 delete from person。很遗憾，啥数据都没有，也没办法根据它生成逆向操作。

# at 445

#240914 17:15:13 server id 1  end_log_pos 510 CRC32 0x6a7a66e4 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=no

SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;

# at 510

#240914 17:15:13 server id 1  end_log_pos 591 CRC32 0x55e4225b 	Query	thread_id=1267	exec_time=0	error_code=0

SET TIMESTAMP=1726305313/*!*/;

BEGIN

/*!*/;

# at 591

#240914 17:15:13 server id 1  end_log_pos 685 CRC32 0x10938b9d 	Query	thread_id=1267	exec_time=0	error_code=0

SET TIMESTAMP=1726305313/*!*/;

delete from person

/*!*/;

# at 685

#240914 17:15:13 server id 1  end_log_pos 716 CRC32 0x1ea4a681 	Xid = 30610

COMMIT/*!*/;

# at 716

3.2.2 row模式

可以看到binlog以 ###开头的几行，WHERE之后，把被删除数据的每一个字段都作为条件嵌入到sql语句中了。条件的顺序，就是表结构的字段顺序。比如说@1对应的就是id，@2对应的就是name。

# at 1574

#240914 17:16:38 server id 1  end_log_pos 1642 CRC32 0x944b1b94 	Query	thread_id=20	exec_time=1260	error_code=0

SET TIMESTAMP=1726305398/*!*/;

BEGIN

/*!*/;

# at 1642

#240914 17:16:38 server id 1  end_log_pos 1695 CRC32 0x435282e2 	Table_map: `tests`.`person` mapped to number 111

# at 1695

#240914 17:16:38 server id 1  end_log_pos 1745 CRC32 0x3063bf8c 	Delete_rows: table id 111 flags: STMT_END_F

### DELETE FROM `tests`.`person`

### WHERE

###   @1=1

###   @2='first'

# at 1745

#240914 17:16:38 server id 1  end_log_pos 1776 CRC32 0x086c2270 	Xid = 3391

COMMIT/*!*/;

3.3 生成逆向操作

根据上面的binlog文件，我们可以通过脚本生成逆向操作。

insert int0 person values (1, 'first');

3.4 重放数据

与 2.4 一致

三、常见工具

目前有一些开源的工具，可以帮助我们解析binlog，并且自动生成binlog记录的操作的逆向操作。

1. binlog2mysql

binlog2sql由美团点评DBA团队(上海)出品，python脚本实现。主要原理是伪装成slave，向master获取binlog，并且根据binlog生成逆向操作。

下载地址：GitHub - danfengcao/binlog2sql: Parse MySQL binlog to SQL you want

在执行之前，需要确认mysql server已设置以下参数：

[mysqld]

server_id = 1

log_bin = /var/log/mysql/mysql-bin.log

max_binlog_size = 1G

binlog_format = row

binlog_row_image = full

获取正向操作：

> python binlog2sql.py -h127.0.0.1 -P13306 -uroot -p --start-file=mysql-bin.000002

Password:

INSERT INTO `tests`.`person`(`id`, `name`) VALUES (1, 'first'); #start 4 end 395 time 2024-09-14 17:16:36

DELETE FROM `tests`.`person` WHERE `id`=1 AND `name`='first' LIMIT 1; #start 426 end 667 time 2024-09-14 17:16:38

1. 通过命令，输入用户名、密码、端口号、地址等，并且指定binlog文件


2. 通过输出，可以看出所有正向操作，以及每个正向操作的时间、binlog位置

获取逆向操作：

> python binlog2sql.py -h127.0.0.1 -P13306 -uroot -p --start-file=mysql-bin.000002 --flashback

Password:

INSERT INTO `tests`.`person`(`id`, `name`) VALUES (1, 'first'); #start 426 end 667 time 2024-09-14 17:16:38

DELETE FROM `tests`.`person` WHERE `id`=1 AND `name`='first' LIMIT 1; #start 4 end 395 time 2024-09-14 17:16:36

1. 命令中，新增一个参数 --flashback，用于指定回滚


2. 通过输出，可以看出所有逆向操作。并且可以看出相对于正向操作来说，逆向操作的顺序是相反的，按时间从后往前排序

还有其他工具，比如说MyFlash等，大家可以自行研究

MyFlash：GitHub - Meituan-Dianping/MyFlash: flashback mysql data to any point

四、总结

前面松哥写了一篇文章和大家聊了 Spring6 中引入的新玩意 AOT（见Spring Boot3 新玩法，AOT 优化！）。

文章发出来之后，有小伙伴问松哥有没有做性能比较，老实说，这个给落下了，所以今天再来一篇文章，和小伙伴们梳理比较小当我们利用 Native Image 的时候，Spring Boot 启动性能从参数上来说，到底提升了多少。

先告诉大家结论：启动速度提升 10 倍以上。

1. Native Image

1.1 GraalVM

不知道小伙伴们有没有注意到，现在当我们新建一个 Spring Boot 工程的时候，再添加依赖的时候有一个 GraalVM Native Support，这个就是指提供了 GraalVM 的支持。

那么什么是 GraalVM 呢？

GraalVM 是一种高性能的通用虚拟机，它为 Java 应用提供 AOT 编译和二进制打包能力，基于 GraalVM 打出的二进制包可以实现快速启动、具有超高性能、无需预热时间、同时需要非常少的资源消耗，所以你把 GraalVM 当作 JVM 来用，是没有问题的。

在运行上，GraalVM 同时支持 JIT 和 AOT 两种模式：

• JIT 是即时编译（Just-In-Time Compilation）的缩写。它是一种在程序运行时将代码动态编译成机器码的技术。与传统的静态编译（Ahead-of-Time Compilation）不同，静态编译是在程序执行之前将代码编译成机器码，而 JIT 编译器在程序运行时根据需要将代码片段编译成机器码，然后再运行。所以 JIT 的启动会比较慢，因为编译需要占用运行时资源。我们平时使用 Oracle 提供的 Hotspot JVM 就属于这种。


• AOT 是预先编译（Ahead-of-Time Compilation）的缩写。它是一种在程序执行之前将代码静态编译成机器码的技术。与即时编译（JIT）不同，即时编译是在程序运行时动态地将代码编译成机器码。AOT 编译器在程序构建或安装阶段将代码转换为机器码，然后在运行时直接执行机器码，而无需再进行编译过程。这种静态编译的方式可以提高程序的启动速度和执行效率，但也会增加构建和安装的时间和复杂性。AOT 编译器通常用于静态语言的编译过程，如 C、C++ 等。

如果我们在 Java 应用程序中使用了 AOT 技术，那么我们的 Java 项目就会被直接编译为机器码可以脱离 JVM 运行，运行效率也会得到很大的提升。

那么什么又是 Native Image 呢？

1.2 Native Image

Native Image 则是 GraalVM 提供的一个非常具有特色的打包技术，这种打包方式可以将应用程序打包为一个可脱离 JVM 在本地操作系统上独立运行的二进制包，这样就省去了 JVM 加载和字节码运行期预热的时间，提升了程序的运行效率。

Native Image 具备以下特点：

• 即时启动：由于不需要 JVM 启动和类加载过程，Native Image 可以实现快速启动和即时执行。


• 减少内存占用：编译成本地代码后，应用程序通常会有更低的运行时内存占用，因为它们不需要 JVM 的额外内存开销。


• 静态分析：在构建 Native Image 时，GraalVM 使用静态分析来确定应用程序的哪些部分是必需的，并且只包含这些部分，这有助于减小最终可执行文件的大小。


• 即时性能：虽然 JVM 可以通过JIT（Just-In-Time）编译在运行时优化代码，但 Native Image 提供了即时的、预先优化的性能，这对于需要快速响应的应用程序特别有用。


• 跨平台兼容性：Native Image 可以为不同的操作系统构建特定的可执行文件，包括 Linux、macOS 和 Windows，即在 Mac 和 Linux 上自动生成系统可以执行的二进制文件，在 Windows 上则自动生成 exe 文件。


• 安全性：由于 Native Image 不依赖于 JVM，因此减少了 JVM 可能存在的安全漏洞的攻击面。


• 与 C 语言互操作：Native Image 可以与本地 C 语言库更容易地集成，因为它们都是在同一环境中运行的本地代码。

根据前面的介绍大家也能看到，GraalVM 所做的事情就是在程序运行之前，该编译的就编译好，这样当程序跑起来的时候，运行效率就会高，而这一切，就是利用 AOT 来实现的。

但是！对于一些涉及到动态访问的东西，GraalVM 似乎就有点力不从心了，原因很简单，GraalVM 在编译构建期间，会以 main 函数为入口，对我们的代码进行静态分析，静态分析的时候，一些无法触达的代码会被移除，而一些动态调用行为，例如反射、动态代理、动态属性、序列化、类延迟加载等，这些都需要程序真正跑起来才知道结果，这些就无法在编译构建期间被识别出来。

而反射、动态代理、序列化等恰恰是我们 Java 日常开发中最最重要的东西，不可能我们为了 Native Image 舍弃这些东西！因此，从 Spring6（Spring Boot3）开始支持 AOT Processing！AOT Processing 用来完成自动化的 Metadata 采集，这个采集主要就是解决反射、动态代理、动态属性、条件注解动态计算等问题，在编译构建期间自动采集相关的元数据信息并生成配置文件，然后将 Metadata 提供给 AOT 编译器使用。

道理搞明白之后，接下来通过一个案例来感受下 Native Image 的威力吧！

2. 准备工作

首先需要我们安装 GraalVM。

GraalVM 下载地址：

• http://www.graalvm.org/downloads/

下载下来之后就是一个压缩文件，解压，然后配置一下环境变量就可以了，这个默认大家都会，我就不多说了。

GraalVM 配置好之后，还需要安装 Native Image 工具，命令如下：

gu install native-image

装好之后，可以通过如下命令检查安装结果：

另一方面，Native Image 在进行打包的时候，会用到一些 C/C++ 相关的工具，所以还需要在电脑上安装 Visual Studio 2022，这个我们安装社区版就行了（visualstudio.microsoft.com/zh-hans/dow…

下载后双击安装就行了，安装的时候选择 C++ 桌面应用开发。

如此之后，准备工作就算完成了。

3. 实践

接下来我们创建一个 Spring Boot 工程，并且引入如下两个依赖：

然后我们开发一个接口：

@RestController

public class HelloController {



    @Autowired

    HelloService helloService;



    @GetMapping("/hello")

    public String hello() {

        return helloService.sayHello();

    }

}

@Service

public class HelloService {

    public String sayHello() {

        return "hello aot";

    }

}

这是一个很简单的接口，接下来我们分别打包成传统的 jar 和 Native Image。

传统 jar 包就不用我多说了，大家执行 mvn package 即可：

mvn package

打包完成之后，我们看下耗时时间：

耗时不算很久，差不多 3.7s 左右，算是比较快了，最终打成的 jar 包大小是 18.9MB。

再来看打成原生包，执行如下命令：

mvn clean native:compile -Pnative

这个打包时间就比较久了，需要耐心等待一会：

可以看到，总共耗时 4 分 54 秒。

Native Image 打包的时候，如果我们是在 Windows 上，会自动打包成 exe 文件，如果是 Mac/Linux，则生成对应系统的可执行文件。

这里生成的 aot_demo.exe 文件大小是 82MB。

两种不同的打包方式，所耗费的时间完全不在一个量级。

再来看启动时间。

先看 jar 包启动时间：

耗时约 1.326s。

再来看 exe 文件的启动时间：

好家伙，只有 0.079s。

1.326/0.079=16.78

启动效率提升了 16.78 倍！

我画个表格对比一下这两种打包方式：

从这张表格中我们可以看到，Native Image 在打包的时候比较费时间，但是一旦打包成功，项目运行效率是非常高的。Native Image 很好的解决了 Java 冷启动耗时长、Java 应用需要预热等问题。

最后大家可以自行查看打包成 Native Image 时候的编译结果，如下图：

看过松哥之前将的 Spring 源码分析的小伙伴，这块的代码应该都很好明白，这就是直接把 BeanDefinition 给解析出来了，不仅注册了当前 Bean，也把当前 Bean 所需要的依赖给注入了，将来 Spring 执行的时候就不用再去解析 BeanDefinition 了。

同时我们可以看到在 META-INF 中生成了 reflect、resource 等配置文件。这些是我们添加的 native-maven-plugin 插件所分析出来的反射以及资源等信息，也是 Spring AOT Processing 这个环节处理的结果。

经常做小程序的小伙伴都曾遇到过这个问题，那就是小程序授权登录，官方文档经常更新，API不时更新迭代，对于基础库版本等等，都有着既定要求。

按照以往方式再去做，发现行不通，折腾一上午，整个人沉默了，原来是官方又进行了大改......

对于小程序登录的问题，借着2025开年之际，给宝子们做一期盘点，来一期《小程序授权登录复盘全攻略》，日常做需求时，大家尽管放心食用，话不多说，直接开始正题！

拜托拜托：点赞收藏是我更新的最大动力！！！

目前为止，微信小程序登录授权，有三种方式，第一种是无感登录，第二种是手机号登录，第三种是用户信息授权登录

比较经典的就是飞猪小程序和顺丰小程序，如果你不知道怎么做，可以去看看它们的样式，一目了然

比如下面这个登录首页面，就属于经典的手机号登陆

点击快速登录，小程序会迅速调用用户的手机号授权

再放一个案例，那就是用户信息授权登录，顾名思义，该登陆主要为了获取用户信息（姓名、性别、地址、昵称等等），用于给个人中心模块做铺垫，图中人名我这边和谐掉，因为也是我前两天刚做完的业务。

至于无感登录，这里就不演示了，因为无感无感，顾名思义就是没有感觉，用户是看不出来授权的，所以直接讲方法就好！

顺便放上小程序开发文档：微信小程序官方文档

1.无感登录

首先无感登录是最简单的，步骤只有两步，第一步是前端调用官方文档API——wx.login，拿到登陆凭证code，通过wx.request（）发起网络请求，随即传给后端。

第二步，后端那边利用code + appid + appsecret这三个数值，调用微信的auth.code2Session接口，拿到用户唯一标识openid 和 会话密钥session_key，随即定义token，将之与openid和session_key关联，最后再返回给前端。

前端拿到token，就很简单了，按照正常操作即可，比如拿token设置请求头、存入vuex、pinia等等，顺理成章直接写即可，大家都能明白。

总结一点：无感登录，说白了，就是拿小程序token的过程，够直白了吧！

至于有人会问，appid和appsecret是什么？看下图即可！（都在你的小程序后台里）

微信小程序开放平台：官方传送门

具体讲一下方法，顺便把代码附在下面，大家可以直接移植！

首先要注意的是，调用wx.login的时候，你的小程序基础库版本，不能低于2.3.1

可以在你的原生小程序工具查看

其次再看看wx.login的传参+返回值，重点关注success和fail，一个是成功回调，一个是失败回调

返回值是code，有时效限制，这里要注意的是，前端的appId，要和后端的appId一致。

有的人拿不同的appId去调用接口，最后会导致500报错！

代码示例：（用uniapp的，将wx.login替换为uni.login即可），example.com/onLogin 这个是事例网址，需要替换为你们后端的接口，主要用来获取token。

wx.login({

  success (res) {

    if (res.code) {

      //发起网络请求

      wx.request({

        url: 'https://example.com/onLogin',

        data: {

          code: res.code

        }

      })

    } else {

      console.log('登录失败！' + res.errMsg)

    }

  }

})

2.手机号登陆

需要注意的是，个人账号，无法使用手机号登录功能，并且该功能是收费的。

标准单价每次组件调用成功，收0.03元，每个小程序账号将有1000次体验额度，该1000次的体验额度为正式版、体验版和开发版小程序共用，超额后，体验版和开发版小程序调用同正式版小程序一样，均收费。

这一要说明一点的是，相信很多人在网上都看到类似encryptedData、iv获取手机号的方法，25年为止，微信又改版了，手机号登录的流程又得到了简化。（前提是使用付费服务）

流程为：调用bindgetphonenumber，返还code，这个code是限时+一次性的，服务器只需要拿着这个code去和微信换手机号就可以了

传送门一：官方手机组件

传送门二获取手机号最新方法
`

<button open-type="getPhoneNumber" bindgetphonenumber="getPhoneNumber"></button>

`
这里要注意一点，如果你用的是uniapp，那么bindgetphonenumber需要换为@getphonenumber

还是通过wx.login拿code，然后调用这个接口，具体要和后端商量，前端的工作并不多，调用而已

参数需要这几个

与此同时，返回值手机号就来了

所以手机号登录没那么复杂，重点是需要付费，不付费的话，让用户自行输入表单，也行，看具体业务实现方式

3.用户信息授权登录

对于用户授权登录的问题，那么就绕不过wx.getUserInfo和wx.getUserProfile的历史渊源了。

早期的小程序开发，大家都是通过wx.getUserInfo拿到用户头像昵称，结果2021年4月，微信社区改版，导致getUserInfo不再有授权流程，开发者只能获取到匿名信息。

比如名字，大家都叫做“微信用户”，而头像，接口返回的都是统一灰色头像。

可这样就带来一个问题，那就是不同用户，昵称头像都一样，完全不方面管理，所以wx.getUserProfile接口应运而生！

这一有一个行为，大家要注意，wx.getUserInfo获取用户信息，不会有底部弹窗，而wx.getUserProfile则会出现下方的底部弹窗（样式看开头），根据你的需求自行选择。

再到2022年10月，微信社区又改版了，就连wx.getUserProfile这个接口，也不给开发者权限了，用户名+头像，全部变成了统一的“微信用户”+灰色头像。

所以如果你实在想获取用户信息，那么利用组件，让用户自行填写，是不错的选择。
`

  getUserProfile(e) {

    wx.getUserProfile({

      desc: '用于完善会员资料', 

      success: (res) => {

        this.setData({

          userInfo: res.userInfo,

          hasUserInfo: true

        })

      }

    })

  }

`

这两天我们开发团队不知道咋的，跟包饺子下锅似的接连出了不少纰漏，有的大有的小，其实开发能力都可以，不是那种能力差导致的问题，我从外部观察，总结了一些出纰漏的原因和解决方案。

先说一下有啥纰漏。

看起来研发该死，但恐怕不全是研发的锅，当然我不是故意找理由，这些纰漏也是研发扛下来了，我只是尝试分析从更具体的原因分析，而不是简单的说一句能力太差、或者水平不够这样没法定位也没法改进的原因。

这些出问题的场景，无一例外都是很紧急的需求，开发加班加点做出来的，代码写的时候很匆忙，测试也是加班加点测的。

常在河边走，哪有不湿鞋？我觉得快和稳之间，对开发来说很难平衡，有些需求强行要那个时间点，最后只能牺牲稳定性求效率。

那怎么避免这种事情发生？

需求可以 delay，代码不能出问题

如果工作量实在大，那就先花点时间列举工作量大的原因。大部分领导其实讲道理的，你能像他说明工作量的确大，事项的确做不完，领导会额外给时间。

我觉得这是比只闷头写代码更有难度的事，也是一种能力的体现，这需要调研充分、思维清晰、表达有条理、和领导沟通的心理等等各项挑战。

只知道埋头苦干，但干不多不一定就是好。

万一要是真的只知道埋头苦干，那也要掌控好自己的节奏，一定要保证代码的质量，平时加加班，周末也来加班，通过拉长时间线的方式多写点代码，而不是通过偷懒、减少代码逻辑的方式。

加班的时候冒冒泡，留点记录，这样即使需求 delay 了，至少自己的态度表达到位了，一般领导也不会责怪。

需求这东西，delay 两天没那么恐怖，反倒是着急出了纰漏，那才是更恐怖的。

慢慢写

写代码很费脑子，要考虑到所有可能的异常场景，还要从业务上闭环，一着急，就容易漏场景，出纰漏，不要着急，细水长流。

想好再写

尤其是后端，新业务的架构设计，一定是要多花时间思考的，要充分考虑到业务的扩展性、未来的维护性、和其他业务对接的兼容性。

比如我最近写的京东商户订单支付，我们已有一套支付中心的系统，而在对接京东的时候，他们的支付其实是通过京东的订单状态回调来做的，我们一开始准备写在支付中心，后来随着三方接口的对接，对京东业务有更深的理解，我们决定做一套新的商户订单支付系统，和原本的支付中心（支付宝、微信支付）做区分。

如果我们当时匆忙的直接嵌入到支付中心，整个系统架构就会很混乱，订单和支付裹在一起，后续既不好维护，也不好扩展。

这样虽然需求有 delay 风险，但整体技术侧的方案，是绝对没问题的。大不了我周末来加班，加班都干不完，那就得赶紧汇报领导了。

包括最开始的人脸也是的，没有调研清楚，光阿里就两套不同的人脸接口，结果先用的贵的一套，后面发现有便宜的，又强行接入便宜的一套。如果一开始能多想想，先调研清楚，可能最后的工时反而更短一些。

专一写代码不要跳

写代码的时候，最好不要来回跳需求写，看起来很牛逼感觉也很吊，实际上很容易出问题，精力消耗太快了，有些场景思考不深入，就有可能埋雷。

决策和执行分开

如果开发过程中又做决策又做执行，尤其是干需求的时候，有的决策问起来吧很耗时间，需求到期上不了线了，就自己做个决策，没有告知其他人。这种场景的雷我也踩了几个。

开发对业务的理解不如运营产品深入，有时候开发觉得的最优决策不是运营想要的，最好不要为了图省隐蔽这些问题。

甩锅技巧

这部分是语言的艺术，就是当纰漏下来了，判责归自己，怎么表达，才是比较得体的。

一直说自己的责任吧，领导会觉得我很菜，一直推脱责任吧，领导又会觉得我不负责。

最好是那种和自己有点关系，但是关系不是那么直接的描述。

或是用于日常沟通，为了避免别人误把锅扣到自己头上。

我总结了同事们常用的有如下技巧：

挺瞧不上这些东西的，也不想花心思想，但有时候职场、工作、社会就是这么贱，人越是老实，就越容易被欺负；越能干活的人，最后会有越来越多的活；希望大家不要重蹈我的覆辙。

每天抽点时间学习和反思，加油，共勉。

Android 越往深处研究，必然离不开NDK,和JNI相关知识

一、前言

Android开发中，最重要的一项技能便是NDK开发，它涉及到JNI,C,C++等相关知识

我们常见的MMKV,音视频库FFmpeg等库的应用，都有相关这方面的知识，它是Android开发人员通往深水区的一张门票。

本文我们就简单介绍JNI,NDK的相关入门知识：

1. JNI方法注册（静态注册，动态注册）

2. JNI的基础数据类型

3. JNI引用数据类型

4. JNI函数签名信息

5. JNIEnv的介绍

6. JNI编译之Cmake

7. 示例：获取JNI返回字符串(静态注册)

8. 示例：调用JNI,JNI调用Java层无返回值方法(静态注册)

9. 示例：调用JNI,JNI调用Java层无返回值方法(带参数)(静态注册)

10. 示例：调用JNI去调用java方法(静态注册)

11. 示例：调用JNI去调用java 变量值(静态注册)

12. 示例：去调用JNI去调用Java带callback方法，带参数(静态注册)

13. 示例：动态注册

二、基础介绍

1. JNI是什么？ JNI(Java Native Interface),它是提供一种Java字节码调用C/C++的解决方案，JNI描述的是一种技术。

2. NDK是什么? NDK(Native Development Kit)

Android NDK 是一组允许您将 C 或 C++（“原生代码”）嵌入到 Android 应用中的工具，NDK描述的是工具集。 能够在 Android 应用中使用原生代码对于想执行以下一项或多项操作的开发者特别有用：

• 在平台之间移植其应用。


• 重复使用现有库，或者提供其自己的库供重复使用。


• 在某些情况下提高性能，特别是像游戏这种计算密集型应用。

3. JNI方法静态注册：

JNI函数名格式（需将”.”改为”—”）：

Java_ + 包名（com.example.auto.jnitest）+ 类名(MainActivity) + 函数名(stringFromJNI)

静态方法的缺点：

• 要求JNI函数的名字必须遵循JNI规范的命名格式；


• 名字冗长，容易出错；


• 初次调用会根据函数名去搜索JNI中对应的函数，会影响执行效率；


• 需要编译所有声明了native函数的Java类，每个所生成的class文件都要用javah工具生成一个头文件；

4. JNI方法动态注册：

Java与JNI通过JNINativeMethod的结构来建立函数映射表，它在jni.h头文件中定义，其结构内容如下：

typedef struct {

    const char* name;

    const char* signature;

    void*       fnPtr;

} JNINativeMethod;

创建映射表后，调用RegisterNatives函数将映射表注册给JVM;

当Java层通过System.loadLibrary加载JNI库时，会在库中查JNI_OnLoad函数。可将JNI_OnLoad视为JNI库的入口函数，需要在这里完成所有函数映射和动态注册工作，及其他一些初始化工作。

5. JNI的基础数据类型对照表：

6. JNI引用数据类型对照表:

7. JNI函数签名信息

由于Java支持函数重载，因此仅仅根据函数名是没法找到对应的JNI函数。为了解决这个问题，JNI将参数类型和返回值类型作为函数的签名信息。

JNI规范定义的函数签名信息格式：  (参数1类型字符…)返回值类型字符

函数签名例子:

JNI常用的数据类型及对应字符对照表:

8. JNIEnv的介绍

注意：在C++创建的子线程中获取JNIEnv，要通过调用JavaVM的AttachCurrentThread函数获得。在子线程退出时，要调用JavaVM的DetachCurrentThread函数来释放对应的资源，否则会出错。

9. JNI编译之Cmake

CMake 则是一个跨平台的编译工具，它并不会直接编译出对象，而是根据自定义的语言规则（CMakeLists.txt）生成 对应 makefile 或 project 文件，然后再调用底层的编译， 在Android Studio 2.2 之后支持Cmake编译。

• add_library 指令
  
  语法：add_library(libname [SHARED | STATIC | MODULE] [EXCLUDE_FROM_ALL] [source])
  
  将一组源文件 source 编译出一个库文件，并保存为 libname.so (lib 前缀是生成文件时 CMake自动添加上去的)。其中有三种库文件类型，不写的话，默认为 STATIC;
  
  
  
  
  • SHARED: 表示动态库，可以在(Java)代码中使用 System.loadLibrary(name) 动态调用；
  
  
  • STATIC: 表示静态库，集成到代码中会在编译时调用；
  
  
  • MODULE: 只有在使用 dyId 的系统有效，如果不支持 dyId，则被当作 SHARED 对待；
  
  
  • EXCLUDE_FROM_ALL: 表示这个库不被默认构建，除非其他组件依赖或手工构建;
  
  
  
  

#将compress.c 编译成 libcompress.so 的共享库

add_library(compress SHARED compress.c)

• target_link_libraries 指令 语法：target_link_libraries(target library <debug | optimized> library2…)  这个指令可以用来为 target 添加需要的链接的共享库，同样也可以用于为自己编写的共享库添加共享库链接。如：

#指定 compress 工程需要用到 libjpeg 库和 log 库

target_link_libraries(compress libjpeg ${log-lib})

• find_library 指令 语法：find_library( name1 path1 path2 ...)  VAR 变量表示找到的库全路径，包含库文件名 。例如：

find_library(libX  X11 /usr/lib)

find_library(log-lib log)  #路径为空，应该是查找系统环境变量路径

示例工程Cmake截图如下：

三、示例工程代码

示例工程截图：

示例MainActivity内需要加载SO:

companion object {

    // Used to load the 'native_kt_demo' library on application startup.

    init {

        System.loadLibrary("native_kt_demo")

    }

}

1. 示例：获取JNI返回字符串(静态注册)

Kotlin 代码

external fun stringFromJNI(): String

JNI层下代码

//extern "C" 避免编绎器按照C++的方式去编绎C函数

extern "C"

//JNIEXPORT ：用来表示该函数是否可导出（即：方法的可见性

//1、宏 JNIEXPORT 代表的就是右侧的表达式： __attribute__ ((visibility ("default")))

//2、或者也可以说： JNIEXPORT 是右侧表达式的别名；

//3、宏可表达的内容很多，如：一个具体的数值、一个规则、一段逻辑代码等

JNIEXPORT

//jstring 代表方法返回类型为Java中的 String

jstring

//用来表示函数的调用规范（如：__stdcall）

JNICALL

Java_com_wx_nativex_kt_demo_MainActivity_stringFromJNI(JNIEnv *env, jobject thiz) {

    std::string hello = "Hello from C++";

    return env->NewStringUTF(hello.c_str());

}

2. 示例：调用JNI,JNI调用Java层无返回值方法(静态注册)

Kotlin代码：

external fun callJNI()

JNI层代码：

extern "C" JNIEXPORT void JNICALL

Java_com_wx_nativex_kt_demo_MainActivity_callJNI(JNIEnv *env, jobject thiz) {

    LOGE("-----静态注册 ， 无返回值方法 调用成功-----");

    jclass js = env->GetObjectClass(thiz);

    jmethodID jmethodId = env->GetMethodID(js, "toast", "(Ljava/lang/String;)V");

    env->CallVoidMethod(thiz, jmethodId, env->NewStringUTF("静态注册 无返回值方法 调用成功"));

}

3. 示例：调用JNI,JNI调用Java层无返回值方法(带参数)(静态注册)

Kotlin代码：

external fun stringFromJNIwithParameter(str: String): String

JNI层代码：

extern "C" JNIEXPORT jstring JNICALL

Java_com_wx_nativex_kt_demo_MainActivity_stringFromJNIwithParameter(JNIEnv *env, jobject thiz, jstring str) {

    const char *data = env->GetStringUTFChars(str, NULL);

    LOGE("-----获取到Java 传来的数据:data %s-----", data);

    env->ReleaseStringChars(str, reinterpret_cast<const jchar *>(data));

    const char *src = "111---";

    const int size = sizeof(data) + sizeof(src);

    char datares[size] = "111---";

    return env->NewStringUTF(strcat(datares, data));

}

4. 示例：调用JNI去调用java方法(静态注册)

Kotlin代码：

external fun callNativeCallJavaMethod()

JNI层代码：

extern "C"

JNIEXPORT void JNICALL

Java_com_wx_nativex_kt_demo_MainActivity_callNativeCallJavaMethod(JNIEnv *env, jobject thiz) {

    jclass js = env->GetObjectClass(thiz);

    jmethodID jmethodId = env->GetMethodID(js, "toast", "(Ljava/lang/String;)V");

    env->CallVoidMethod(thiz, jmethodId, env->NewStringUTF("jni 通过反射调用 java toast方法"));

}

5. 示例：调用JNI去调用java 变量值(静态注册)

Kotlin代码：

external fun callNativeCallJavaField()

JNI层代码：

extern "C"

JNIEXPORT void JNICALL

Java_com_wx_nativex_kt_demo_MainActivity_callNativeCallJavaField(JNIEnv *env, jobject thiz) {

    jclass js = env->GetObjectClass(thiz);

    jfieldID jfieldId = env->GetFieldID(js, "androidData", "Ljava/lang/String;");

    jstring newDataValue = env->NewStringUTF("四海一家");

//    jclass js = env->GetObjectClass(thiz);

    jmethodID jmethodId = env->GetMethodID(js, "toast", "(Ljava/lang/String;)V");

    env->CallVoidMethod(thiz, jmethodId, newDataValue);

//    env->SetObjectField(thiz, jfieldId, newDataValue);

}

6. 示例：去调用JNI去调用Java带callback方法，带参数(静态注册)

Kotlin代码：

external fun callNativeWithCallBack(callBack: NativeCallBack)

JNI层代码：

extern "C"

JNIEXPORT void JNICALL

Java_com_wx_nativex_kt_demo_MainActivity_callNativeWithCallBack(JNIEnv *env, jobject thiz, jobject call_back) {

    LOGE("-----静态注册 ， callback 调用成功-----");

    jclass js = env->GetObjectClass(call_back);

    jmethodID jmethodId = env->GetMethodID(js, "nmd", "(Ljava/lang/String;)V");

    env->CallVoidMethod(call_back, jmethodId, env->NewStringUTF("我是Jni Native层callBack回调回来的数据值"));

}

7. 示例：动态注册
Kotlin代码：

external fun dynamicRegisterCallBack(callBack: NativeCallBack)

JNI层代码：

void regist(JNIEnv *env, jobject thiz, jobject call_back) {

    LOGD("--动态注册调用成功-->");

    jclass js = env->GetObjectClass(call_back);

    jmethodID jmethodId = env->GetMethodID(js, "nmd", "(Ljava/lang/String;)V");

    env->CallVoidMethod(call_back, jmethodId, env->NewStringUTF("我是Jni Native层动态注册callBack回调回来的数据值"));

}



jint RegisterNatives(JNIEnv *env) {

    jclass activityClass = env->FindClass("com/wx/nativex/kt/demo/MainActivity");

    if (activityClass == NULL) {

        return JNI_ERR;

    }

    JNINativeMethod methods_MainActivity[] = {

            {

                    "dynamicRegisterCallBack",

                    "(Lcom/wx/nativex/kt/demo/NativeCallBack;)V",

                    (void *) regist

            }

    };



    return env->

            RegisterNatives(activityClass, methods_MainActivity,

                            sizeof(methods_MainActivity) / sizeof(methods_MainActivity[0]));

}





//JNI_OnLoad   java

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {

    LOGE("-----JNI_OnLoad 方法调用了-----");

    JNIEnv *env = NULL;

    if (vm->GetEnv((void **) &env, JNI_VERSION_1_6) != JNI_OK) {

        return JNI_ERR;

    }



    jint result = RegisterNatives(env);

//    函数注册

    return JNI_VERSION_1_6;

}

总结

本文简单介绍了NDK编程中JNI的基础：并写了相关示例Demo代码

感谢阅读：

欢迎用你发财的小手： 点点赞、收藏收藏，或者 关注关注

这里你会学到不一样的东西

项目地址

Gitee地址

Github地址

原文《2024年度总结，回顾迅排设计发展历程》，首发于公众号：品味前端

大家好，这里是茶无味的一天。

去年我突然决定裸辞，褪去天命打工人的身份，想拿出一两年时间来专注做一件自己想做的事情，开始了昼夜狂奔的工作模式。由于大部分时间都在搞开发，所以姑且就称自己为独立开发者吧。

时光荏苒，转眼间我就踉跄的踏入了 2025，无论成败，也必须对过去一年稍微做下总结了。

新年伊始，独立开发的道路即将走过第一个年头，这一年中我的故事围绕着「迅排设计」在展开，所以这篇文章就带大家回顾下这个项目的发展过程。

拉开序幕

三年前的一天，领导让我仿造一个稿定设计，这对于程序员来说实在太过陌生，我就说先去搜一下看看，然后傻眼了，当时只觉得这根本就是不可能完成的任务。

过了几天领导又来问，表示无论做成啥样都行，我说试试吧。于是就开始了全世界的统一操作：打开 Github，看看有没有现成的项目，拿来改改然后交差（何同学工作室点头表示这个我们熟）。还没来得及为自己的机智窃喜，我又傻眼了，当时搜遍全网后发现，开源的项目都是功能少 bug 多、界面还很抽象，能用的竟一个没有！

虽然我心底里在打退堂鼓，身体却很诚实，行动派的我还是决定做了再说，毕竟越难啃的骨头往往越有价值。而且我也意识到，这几年浮现的众多编辑器产品无一不在向我们证明：Web 前端可以做很多复杂且有深度的事情，这正是自我提升的机会。我这样想着，写下了项目的第一行代码。

从项目中搜索到的记录来看，保留至今最早的代码落款于 2021 年 7 月，彼时的我凌晨 2 点还在敲代码，而这样的夜晚至今也已数不清经历了多少个。

当然班还要继续上，平时仍是对接口、还原 UI 图的无味日常，然后挤时间出来做这个图片设计工具，连周末也在敲代码（我可不想在公司加班当工贼啊），一个多月后原型版勉强可用，当时就长这个样：

在这个过程中我收获不少满足感，最开始的自我怀疑便一扫而空，也默默担起了 Owner 的角色，决定独立撑起项目。

没有时间，我就跟组长沟通少排点活，不然在多个项目间来回横跳实在无法集中精力展开工作。

没有产品经理，我就把市面上所有能找到的在线设计器全都用了个遍，倒推关键的功能点，再逐一开发。

没有 UI 设计师，我就尽量把界面做得清爽。这好比人不会化妆和穿搭吧，那我凭什么想着艳压群芳呢，保持干净整洁给人的感觉也不会差的。

在经历三个月后，项目顺利上线。这便是迅排设计的前身了，如今回看当时功能界面都挺简单的，不过能看出来和上面那个丑到没边的是同一个项目吗：

然而上线后不久，项目就一直停摆。

由于公司业务长期陷入困境，加之大环境冲击业绩不断下滑，我们也开始掉进内卷的泥潭中挣扎。公司开始了严抓考勤、要求义务加班等操作，甚至取消下午茶、推迟发放工资，很快一批接一批的裁员，最后我也离开了公司。

2022 年中旬，我在掘金写了第一篇年中总结，也是第一次分享做这个项目的心路历程，有不少人开始在那时关注我，而我也是在那时候埋下了将项目开源的种子。

失业加上疫情，中间空白了很长一段时间什么都没做。大约一年后，我重启了这个项目，对代码进行了一些重构，并总结出海报设计的几大要素：图片、文字、创意和排版。

我们的编辑器旨在提供图片文字等素材的同时，更能帮助用户迅速地完成排版，因此取名“迅排设计”，在 2023 年 7 月正式以开源形式出道，项目英文名称：poster-design

项目开源两天后 Github Star 数破百，给阮一峰老师投稿被收录到其周刊（第 263 期）：开源软件如何赚钱中，「迅排设计」开始被更多人看到。

此后开源中国等网站陆续收录了项目，HelloGitHub 收录为 2023 年度 JavaScript 热门项目（相关文章）。

2024 年 3 月还冲上过一次 GitHub Trending 全站热门，如今迅排已经被越来越多人所熟知....

未来计划

来聊聊开源的一些安排吧。

2024 下半年的重心基本是在商业版中，也就是迅排设计 Plus 的开发，其中做了不少差异化的更新。

其实迅排刚开源的时候，只是想着弄个在线网站才能更好地演示功能，后来我发现不少普通用户是真的在使用我们的在线版做图，于是萌生出一个想法，干脆就把C端 SaaS 平台慢慢做起来呗。

所以开源版渐渐独立，现在只是迅排设计的一部分，或者说是核心编辑器。

而在一开始做 Plus 商业版时，我也曾尝试完全基于开源仓库迭代，以保持两边同步更新，但发现行不通，而且也会被迫让往后的 PR 变得困难，后来便单独写了个服务端 Demo 让开源版脱机运行。

开源是自由的，我们欢迎并接纳任何代码提交和想法。

持续推动开源项目的发展也是今年的一项计划，我希望能让更多人参与进来，传递开源的价值。

另外今年也会更积极地与外部产品或开源项目建立合作关系，交换流量和增加曝光。2024 年几乎没有怎么推广过项目，发的文章集中在公众号和粉丝群，曝光度是比较低的。

Plus 版付费产品

为了满足企业数字化升级或转型的需要，我开始了商业版计划。由于这是一个前后台完整、大而全的项目，所以代号叫 Plus 版，这是过去半年多的工作重心。

商业化的核心是为客户提供价值或解决问题，在“能服务好客户”和“能给客户提供好服务”之间，我选择了后者。我认为前者谁都可以做到，所以后者更有价值。

考虑到迅排设计本身仍有很大的成长空间，所以确定了长期更新、不断完善这个主基调，为了能快速更新迭代，还专门建立了一套升级维护的系统体系。

在销售和服务了一些客户之后，我对自己的产品也有了更清晰的认识和规划。这期间版本和定价做了多次调整，现在已经明确就落地两套方案：

当然客户最关心的通常是定价，而这也是一开始困扰我最大的问题。

普通产品的定价模型通常是成本 + 利润，但我们却无法这么做。因为软件开发本身是一项复杂的工程，且需要不断进行技术创新和产品研发，如果以传统的人力成本计算报价，可能会忽略市场和客户的需求，导致产品难以销售。

类似产品的大公司依靠人才供应链和多年品牌积累，维持住了自身的市场份额，他们的定价能一定程度反映市场需求，却很难直接拿来参考。

我们的商业化模式在市场的优势是什么呢？其实是自身技术和经验的积累。相比之下品牌价值和口碑还没做起来的时候，基本没有溢价资格，毕竟我们才刚起步。

事实上无论任何行业，基本都是从性价比开始、然后追求高品质、最后才能获得高溢价。十几年前外国对 "Made In China" 有着刻板印象，难道说是当时的中国企业不想做高端产品吗？凡事都需要一个过程。

所以我最终思考后决定完全抛弃利润，甚至让出成本，仅以技术支持定价，这样前期才好销售。

只要做好长期策略，并根据市场和客户反馈灵活调整，后面不断提升产品功能价值，提升差异化、服务满意度等方面来持续影响客户愿意支付的价格，慢慢还是有可能盈利的。

而现阶段迅排 Plus 企业服务的定价，实际上出售的也是信心。

随着近段时间产品功能的完善、以及初期客户的良好反馈，这就是我们不断建立信心的过程。

还有一些客户会提出更多样化的需求，很遗憾我做不了特殊定制化。能否把握客户预期也是非常重要的，相信所有小微创业者都一样，做预期不明确的事情无异于杀鸡取卵。

未来的路还很长，对于迅排自身发展的定位我基本锚定在两点：

SaaS 平台规划

我们的项目虽然是独立开发的，但其实不比公司做的产品差，可以满足大部分普通用户的日常做图需求。这半年来迅排设计官网一直在低调运营，并随着迅排 Plus 版的开发进程不断完善自身。

接下来迅排设计将致力于做免费在线创作平台，编辑器和平台的模板、素材图片、字体等均为用户免费使用！后续则是希望通过和 AI 等技术的结合，比如打造一些增值付费的智能化工具来盈利。

红海市场竞争激烈，做这个平台目的是想回馈忠实的粉丝。我希望能努力将「迅排设计」打造成小众领域中用户口碑最好的在线设计产品，所以也一直在刻意地放缓扩大市场。

目前平台有 3000+ 注册用户，我基本每周会抽空更新点模板，虽然不是设计师出身，但经手过上千张海报，多少也摸索出一点门道，目前还在不断学习中。至今共做了 400+ 模板与组件，预计今年网站可以完善到 2000+ 以上的模板。

随着平台使用人数增加，就要着手开发后台统计与数据可视化的功能了。目前的网站访问数据是用“不蒜子”这个插件统计的，可以看到去年官网总 uv 数 8w，总 pv 数 15w。

接下来为了平台更好地发展，将会在适当的时候进行一次数据清理，届时会在官网通知，所有用户的作品数据和上传文件可能被重置。

网站开销

最后来聊点别的吧，复盘一下我从三年前至今的网站开销一共是多少。

服务器 1 号购于 2021 年 7 月，配置 1h2g，带宽 2 M，是最早服务迅排的机器，当时购买三年花费是：￥247

服务器 2 号购于 2022 年 3 月，配置 1h2g，带宽 1 M，购买三年花费：￥177。当时打折随意买的，当测试机，好像没怎么用过。

以上两台机器均已“陨落”，没有选择续费（价格翻十几二十倍是常规操作）。所以后面又买了 5 年的 2h4g 3M 服务器，花费￥1080，这就是目前迅排设计服役中的机器。

域名最后一次续费花了 ￥79，当时用的还是 .com ，已经涨到 90 元（几年前买入时才 45 元），虽然钱不多但无法接受连年涨价，所以干脆换了 .cn，一口气买了五年 ￥181。（旧域名后来竟被菠菜网站买了去，法克！）

七牛云oss的流量费用，由于我没有上 CDN、且限制传输大文件，消耗比较小，算个 20 元让它有些参与感吧。

后面还买了阿里的那个 99 服务器，2h2g 带宽 3M，当个副机用。

247 + 177 + 1080 + 79 + 181 + 20 + 99

统计下来的总花费约为：￥1883

这就是我三年来的所有建站成本，其实正常的网站运维成本肯定是我的好多倍，只是我比较爱折腾，在网站的访问速度、图片字体压缩等方面也下了不少功夫，才勉强让迅排运行时表面上看起来毫不费力。

当然最主要还是穷，为爱发电靠的全是个人极致的“勤俭持家”~ 现在哪怕我不再花费一分钱，「迅排设计」也仍然能坚持运行至 2028 年 😂

不知到那时候我们能换上豪华顶配性能溢出的服务器吗？

前言

实践是最好的学习方式，技术也如此。

一、简介

• RecyclerView 是列表；


• 好处：更高效率的列表控件；


• 用法：重点 RecycleerView.Adapter 的写法；可以通过 LayoutManager（布局管理器）来决定布局的样式，是线性的、网格列表还是瀑布流列表；


• RecyclerView 列表是如何实现显示的 ？
  
  
  
  • 是将数据放到对应的位置上，根据数据内容的数量来显示（即告诉列表有多少个条目） ；
  
  
  
  

二、Adapter

• 是什么
  
  
  
  
  • 适配器、连接器；
  
  
  
  


• 为什么要有 Adapter？
  
  
  
  
  • 列表中不只有一条数据，不像 TextView、ImageView 一样，一个控件对应一条数据；
  
  
  • 列表形式的数据，如何将多个布局与多个数据连接起来？中间就通过 adapter，将数据放到对应的控件的位置；
  
  
  
  


• Adapter 的分类
  
  
  
  
  • ArrayAdapter：简单列表；
  
  
  • SimpleAdapter：图文列表；
  
  
  • BaseAdapter：图文复杂列表 ；
  
  
  
  

三、示例

1、背景

用 RecyclerView 列表显示各个城市天气数据

2、代码

• FutureWeatherAdapter 是一个自定义的适配器类，它继承自 RecyclerView.Adapter 类；在泛型参数中，指定了一个内部类 WeatherViewHolder 作为适配器的视图持有者
  
  
  
  
  • WeatherViewHolder 是用于在 RecyclerView 中显示每个天气数据的视图持有者类；
  
  
  • 通常情况下，你会在适配器内部定义一个继承自 RecyclerView.ViewHolder 的内部类来表示列表项的视图结构和布局
  
  
  
  


• onCreateViewHolder() 方法用于创建 ViewHolder，即创建用于显示单个天气条目的视图，并返回 ViewHolder 对象；使用布局填充器从 XML 布局文件中实例化视图，并将其传递给自定义的 ViewHolder 对象。
  
  
  
  
  • 在创建新的 ViewHolder 实例时调用。当 RecyclerView 需要显示新的列表项时，会调用该方法来创建一个 ViewHolder 对象 ；
  
  
  • onCreateViewHolder() 返回的 ViewHolder 对象会被 RecyclerView 用于显示列表项。当 RecyclerView 需要显示新的列表项时，它会调用 onCreateViewHolder() 方法来创建一个新的 ViewHolder 对象，并将其返回
  
  
  
  


• onBindViewHolder() 方法用于将数据绑定到 ViewHolder 上，即将具体的天气数据填充到对应的视图控件中。在这个方法中，获取当前位置的天气数据对象，然后将其属性分别设置到 ViewHolder 中的各个 TextView 和 ImageView 中；
  
  
  
  
  • 方法在 RecyclerView 需要将数据绑定到 ViewHolder 以显示新的列表项时被调用。当 RecyclerView 中的列表项需要更新或者需要显示新的列表项时，会调用该方法；
  
  
  
  


• getItemCount() 方法用于获取数据集中的条目数，即天气数据列表的大小；
  
  
  
  
  • getItemCount() 方法返回的数据会告诉 RecyclerView 有多少个列表项需要在屏幕上显示。当 RecyclerView 需要确定列表的大小时，它会调用 getItemCount() 方法
  
  
  
  


• 内部类 WeatherViewHolder 继承自 RecyclerView.ViewHolder，用于持有每个天气条目的视图控件的引用；在构造方法中，通过传入的视图参数找到并引用了各个视图控件；
  
  

  
  
  public class FutureWeatherAdapter extends RecyclerView.Adapter<com.example.weatherapp.adapter.FutureWeatherAdapter.WeatherViewHolder> {
  
          private Context mContext;  // 上下文
  
          private List<DayWeatherBean> mWeatherBeans;  // 数据
  
  
  
          public FutureWeatherAdapter(Context mContext, List<DayWeatherBean> mWeatherBeans) {
  
              this.mContext = mContext;
  
              this.mWeatherBeans = mWeatherBeans;
  
          }
  
  
  
          // 先创建ViewHolder再将数据绑定
  
          @NonNull
  
      @Override
  
      public WeatherViewHolder onCreateViewHolder(@NonNull ViewGr0up parent, int viewType) {
  
          // onCreateViewHolder()方法负责创建ViewHolder并将其返回给RecyclerView
  
          View view = LayoutInflater.from(mContext).inflate(R.layout.weather_item_layout, parent, false);  // 布局
  
          WeatherViewHolder weatherViewHolder = new WeatherViewHolder(view);
  
          return weatherViewHolder;
  
      }
  
      
  
  
  
      @Override
  
      public void onBindViewHolder(@NonNull WeatherViewHolder holder, int position) {
  
          // onBindViewHolder()方法负责将数据绑定到ViewHolder
  
          // holder: 表示要绑定的ViewHolder对象，position: 表示ViewHolder在RecyclerView中的位置
  
          // onBindViewHolder()方法负责将数据填充到ViewHolder的视图中
  
          // 它会被调用多次，每次RecyclerView需要显示一个新的ViewHolder时都会调用
  
          DayWeatherBean weatherBean = mWeatherBeans.get(position);  // 拿到当前位置的JavaBean对象
  
          holder.tvWeather.setText(weatherBean.getWea());
  
          holder.tvTem.setText(weatherBean.getTeamDay());
  
          holder.tvAir.setText(weatherBean.getWin_speed());
  
          holder.tvWin.setText(weatherBean.getWin());
  
          holder.tvTemLowHigh.setText(weatherBean.getTeamNight());
  
          holder.ivWeather.setImageResource(getImgResOfWeather(weatherBean.getWeaImg()));
  
      }
  
  
  
      // 总共有多少个条目
  
      @Override
  
      public int getItemCount() {
  
          return (mWeatherBeans == null) ? 0 : mWeatherBeans.size();
  
      }
  
  
  
      class WeatherViewHolder extends RecyclerView.ViewHolder {
  
          TextView tvWeather, tvTem, tvTemLowHigh, tvWin, tvAir;
  
          ImageView ivWeather;
  
  
  
          public WeatherViewHolder(@NonNull View itemView) {
  
              super(itemView);
  
  
  
              tvWeather = itemView.findViewById(R.id.tv_weather);
  
              tvAir = itemView.findViewById(R.id.air);
  
              tvTem = itemView.findViewById(R.id.tv_tem);
  
              tvTemLowHigh = itemView.findViewById(R.id.tv_tem_low_high);
  
              tvWin = itemView.findViewById(R.id.tv_win);
  
              ivWeather = itemView.findViewById(R.id.iv_weather);
  
          }
  
      }
  
  

  
  

你好，我是猿java。

1. 网上关于 CMS的文章很多，为什么要重复造车轮？

答：网上很多关于 CMS收集器的文章写得不够具体，有的甚至一知半解，更多的是不假思索的转载，想通过自己对 CMS的理解以及大量资料的佐证，提供更具体形象正确的分析。

2. CMS已经被弃用，为什么还要分析它？

答：首先，CMS收集器依然是面试中的一个高频问题；
其次，CMS作为垃圾收集器的一个里程碑，作为 Java程序员，不了解原理，于情于理说不过去；

3. JVM已经把垃圾回收自动化了，为什么还要讲解 CMS？

答：排查生产环境的各种内存溢出，内存泄漏，垃圾回收导致性能瓶颈等技术问题，如果不懂原理，如何排查和优化？

温馨提示：如果没有特殊说明，本文提及的虚拟机默认为 HotSpot虚拟机。

背景

首先，了解下 HotSpot虚拟机中 9款垃圾回收器的发布时间及其对应的 JDK版本，如下图：

接着，了解下 CMS垃圾回收器的生命线：

• 2002年9月，JDK 1.4.1 版本，CMS实验性引入；


• 2003年6月，JDK 1.4.2 版本，CMS正式投入使用；


• 2017年9月，JDK 9 版本，CMS被标记弃用；


• 2020年3月，JDK 14 版本，CMS从 JDK中移除；

效力 18年，一代花季回收器，从此退出历史舞台；

什么是垃圾

既然分析的是垃圾回收器，那么，我们首先需要知道：在 JVM 中，什么是“垃圾”？

这里的“垃圾”用了双引号，是因为它和我们生活中理解的垃圾不一样。在 JVM中，垃圾（Garbage）是指那些不再被应用程序使用的对象，也就是说这些对象不再可达，即对象已死。

如何判断对象不可达（已死）？

在 JVM中，通过一种可达性分析（Reachability Analysis）算法来判断对象是否可达。 该算法的基本思路是：通过 GC Roots 集合里的根对象作为起始点，一直追踪所有存在引用关系的对象（这条引用关系链路叫做引用链 Reference Chain）， 如果某对象到 GC Roots之间没有引用链，那么该对象就是不可达。 如下图，obj4， obj5，obj6 尽管相互直接关联，但是没有 GC Root连接，所以是不可达，同理 obj7也不可达： 

关于可达性分析，还有一种方法是引用技术算法，该方法的思路是：在对象中添加一个计数器，增加一次引用计数器 +1，减少一次引用计数器 -1，当计数器始终为 0时代表不被使用，这种方法一般是用于 Python的CPython 和微软的COM（Component Object Model）等技术中，JVM中使用的是可达性分析算法，这点需要特别注意。

哪些对象可以作为 GC Roots？

GC Roots 是 GC Root的集合，本质上是一组必须活跃的对象引用，主要包含以下几种类型：

虚拟机栈中的引用对象：每个线程的虚拟机栈中的局部变量表中的引用。这些引用可能是方法的参数、局部变量或临时状态。

方法区中的类静态属性引用对象：所有加载的类的静态字段。静态属性是类级别的，因此它们在整个Java虚拟机中是全局可访问的。

方法区中的常量引用对象：方法区中的常量池（例如字符串常量池）中的引用。

本地方法栈中的JNI引用：由 Java本地接口（JNI）代码创建的引用，例如，Java代码调用了本地 C/C++库。

活跃的 Java线程：每个执行中的Java线程本身也是一个GC Root。

同步锁（synchronized block）持有的对象：被线程同步持有的对象。

Java虚拟机内部的引用：比如基本数据类型对应的Class对象，一些常见的异常对象（如NullPointerException、OutOfMemoryError）的实例，系统类加载器。

反射引用的对象：通过反射API持有的对象。

临时状态：例如，从Java代码到本地代码的调用。

这里举个简单的例子来解释 GC Root 以及 GC Root可达对象，如下代码：

	

public class RootGcExample {

    private static Object sObj = new Object(); // 静态字段 sObj是 Gc Root



    private static void staticMethod() {

      Object mObj = new Object(); // 方法局部变量 mObj是 Gc Root

      //  ...

    }



    public static void main(String[] args) {

        Object obj = new Object(); // 局部变量obj 是 Gc Root

        staticMethod();

    }

}

上述例子中，sObj 是一个静态变量引用，指向了一个 Object对象，因此，sObj是一个 Gc Root， 在staticMethod静态方法中，mObj 是一个方法局部变量，它也是一个 Gc Root， 在 main方法中，obj也是一个Gc Root。堆中的 Object对象就是 GC Root可达对象，上述关系可以描绘成下图：

回收哪里的垃圾？

从 CMS 简介可以知道 CMS是用于老年代的垃圾回收，但是对于这种抽象的文字描述，很多小伙伴肯定还是没有体感， 因此，我们把视角放眼到整个 JVM运行时的内存结构上，从整体上看看垃圾回收器到底回收的是哪些区域的垃圾， CMS 又是回收哪里的垃圾，如下图：

垃圾在哪里？

在了解了“垃圾”在 JVM中是如何定义之后，我们不禁会问到：这些“垃圾”存放在哪里呢？

在回答这个问题之前，我们先来了解 JVM的内存结构，根据 Java虚拟机规范，JVM内存包含以下几个运行时区域，如下图： 

为了更好地理解 JVM内存结构，这里对各个区域做一个详细的介绍：

• 年轻代：Young Generation，大部分的对象都是在这里创建。年轻代又分为一个 Eden区和两个 Survivor区（S0和S1）。这里的大部分对象生命周期比较短，会被垃圾回收器快速回收。


• 老年代：Old Generation 或 Tenured Generation，在年轻代中经过多次垃圾回收仍然存活的对象会被移动到老年代，或者一些大对象会直接被分配到老年代，这里的对象一般存活时间较长，垃圾回收频率较低。


• 永久代：Permanent Generation，PermGen，Java 8之前版本的叫法，用于存放类信息、方法信息、常量等。在 Java 8及之后的版本，永久代被元空间（Metaspace）所替代。


• 元空间：Metaspace，Java 8及之后版本的叫法，用于存放类的元数据信息，它使用本地物理内存，不在 JVM堆内。

关于方法区有一个误区：JDK 8以前，HotSpot虚拟机为了像堆一样管理方法区的垃圾回收，就使用永久代来实现方法区，因此有人就把方法区直接叫做永久代，而其它虚拟机不存在永久代的概念，因此，方法区如何实现属于虚拟机内部的机制，不是 JVM统一规范。另外，HotSpot发现永久代实现方法区这种做法会导致内存溢出，因此从 JDK8开始，把永久代彻底废除，改用和 JRockit一样的元空间。方法区也改用本地内存实现。

通过上述 JVM内存区域的介绍，我们可以发现 JVM各个内存区域都可能产生垃圾，只是程序计算器，本地方法区，虚拟机栈 3个区域随线程而生，随线程而亡，垃圾被自动回收，方法区回收效果比较差，而堆中的“垃圾”才是回收器关注的重点，因此，垃圾收集器重点关注的是 JVM的堆，而 CMS回收的是堆中的老年代，如下图：

到这里为止，我们已经从 JVM内存结构视角上掌握了垃圾收集器回收的区域以及 CMS 负责的区域。

接下来，分析一下 GC回收常用的几个重要技术点：三色标记法（Tricolor Marking），卡表（Card Table），写屏障（Write Barrier），理解它们可以帮助我们更好地去理解 GC回收的原理。

几个重要技术点

三色标记法

在垃圾收集器中，主要采用三色标记算法来标记对象的可达性：

• 白色：表示对象尚未被访问。初始状态时，所有的对象都被标记为白色。


• 灰色：表示对象已经被标记为存活，但其引用的对象还没有全部被扫描。灰色对象可能会引用白色对象。


• 黑色：表示对象已经被标记为存活，并且该对象的所有引用都已经被扫描过。黑色对象不会引用任何白色对象。

三色标记算法的工作流程大致如下：

卡表

对于分代垃圾回收器，势必存在一个跨代引用的问题，通常会使用一种名为记忆集（Remembered Set）的数据结构，它是一种用于记录从非收集区指向收集区的指针集合的数据结构。

而卡表就是最常用的一种记忆集，它是一个字节数组，用于记录堆内存的映射关系，下面是 HotSpot虚拟机默认的卡表标记逻辑：

// >> 9 代表右移 9位，即 2^9 = 512 字节

CARD_TABLE[this address >> 9] = 0;

每个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块叫做“卡页（Card Page）”。因为卡页代表的是一个区域，所以可能存在很多对象，只要有一个对象存在跨代引用，就把数组的值设为1，称该元素“变脏（Dirty）”，该卡页叫“脏页（Dirty Page）”，如下：

	// >> 9 代表右移 9位，即2^9=512

CARD_TABLE[this address >> 9] = 1;

当垃圾回收时，只要筛选卡表中有变脏的元素，即数组值为 1，就能判断出其对应的内存区域存在对象跨代引用，卡表和卡页的关系如下图：

写屏障

在 HotSpot虚拟机中，写屏障本质上是引用字段被赋值这个事件的一个环绕切面（Around AOP），即一个引用字段被赋值的前后可以为程序提供额外的动作（比如更新卡表），写屏障分为：前置写屏障（Pre-Write-Barrier）和后置写屏障（Post-Write-Barrier）2种类型。

需要注意的是：这里的写屏障和多线程并发中的内存屏障不是一个概念。

分析完几个重要的技术点之后，接下来，我们正式分析 CMS回收器。

CMS 简介

CMS 是 Concurrent Mark Sweep 的简称，中文翻译为并发标记清除，它的目标是减少垃圾回收时应用线程的停顿时间，并且实现应用线程和 GC线程并发执行。

CMS 用于老年代的垃圾回收，使用的是标记-清除算法。通过 -XX:+UseConMarkSweepGC 参数即可启动 CMS回收器。

在 CMS之前的 4款回收器（Serial，Serial Old，ParNew，Parallel Scavenge） ，应用线程和 GC线程无法并发执行，必须 Stop The World（将应用线程全部挂起）， 并且它们关注的是可控的吞吐量，而 CMS回收器，应用线程和 GC线程可以并发执行，目标是缩短回收时应用线程的停顿时间，这是 CMS和其它 4款回收器本质上的区别，也是它作为里程碑的一个标志。

CMS 回收过程

从整体上看，CMS 垃圾回收主要包含 5个步骤（网上很多 4，6，7个步骤的版本，其实都大差不差，没有本质上的差异）：

整个过程可以抽象成下图：

在讲解回收过程之前，先分析三色标记法，这样可以帮助我们更好地去理解 GC的原理。

1. 初始标记

初始标记阶段会 Stop The World（STW），即所有的应用线程（也叫 mutator线程）被挂起。

该阶段主要任务是：枚举出 GC Roots以及标识出 GC Roots直接关联的存活对象，包括那些可能从年轻代可达的对象。

那么，GC Roots是如何被枚举的？GC Roots的直接关联对象是什么？为什么需要 STW？

GC Roots是如何被枚举的？

通过上文对 GC Roots的描述可知，作为 GC Roots的对象类型有很多种，遍及 JVM中的多个区域，对于现如今这种大内存的 VM，如果需要临时去扫描各区域来获取 GC Roots，那将是很大的一个工程量，因此，JVM采用了一种名为 OopMap（Object-Oriented Programming Map）的数据结构，它用于在垃圾收集期间快速地定位和更新堆中的对象引用（OOP，Object-Oriented Pointer）。

OopMap是在 JVM在编译期间生成的，主要作用是提供一个映射，通过这个映射垃圾收集器可以知道在特定的程序执行点（如safepoint）哪些位置（比如在栈或寄存器中）存放着指向堆中对象的引用，这样就可以快速定位 GC Roots。

使用OopMap的优点包括：

• 提高效率：OopMap使得垃圾收集器能够快速准确地找到和更新所有的对象引用，从而减少垃圾收集的时间。


• 减少错误：手动管理对象引用的位置容易出错，OopMap提供了一种自动化的方式来追踪这些信息。


• 便于优化：由于 OopMap是在编译时生成的，编译器可以进行优化，比如减少需要记录的引用数量，从而减少垃圾收集的开销。

在 HotSpot虚拟机中，OopMap是实现精确垃圾收集的关键组件之一。

什么是 GC Roots直接关联的对象？

所谓直接关联对象就是 GC Root直接引用的对象，下面以一个示例来说明，如下代码：

	

public class AssociatedObjectExample {



  public static void main(String[] args) {

    Associated obj = new Associated(); // Associated 是 GC Root obj 直接关联

    ((Associated) obj).bObj = new BigObject(); // BigObject是 GC Root obj 的间接关联的对象，BigObject是一个大对象，直接分配到老年代

  }



  static class Associated {

    BigObject bObj; // 与Associated对象直接关联的对象

  }



  static class BigObject {

    // 其它代码

  }

}

上述例子中，obj是一个 GC Root，Associated对象就是它的直接关联对象，bObj是一个 GC Root，BigObject对象是它的直接关联对象，obj可以通过 Associated对象间接关联 到 BigObject对象，但 BigObject对象不是 obj的直接关联对象，而是间接关联对象。 整个关联关系可以描绘成下图：

为什么需要 STW？

为什么初始标记阶段需要 Stop The World？这里主要归纳成两个原因：

2.并发标记**

这里的并发是指应用线程和 GC线程可以并发执行。

在并发标记阶段主要完成 2个事情：

因为应用线程仍在继续工作，因此老年代的对象可能会发生以下几种变化：

• 新生代的对象晋升到老年代；


• 直接在老年代分配对象；


• 老年代对象的引用关系发生变更；

为了防止这些并发修改被遗漏，CMS 使用了后置写屏障（Write Barrier）机制，确保这些更改会被记录在“卡表（Card Table）”中，同时将相应的卡表条目标记为脏（dirty），以便后续处理。

如下图：从 GC Roots追溯哦所有可达对象，并将它们修改为已标记，即黑色。

当老年代中，D 到 E到引用被修改时，就会触发写屏障机制，最终 E就会被写进脏页，如下图： 

并发标记会出现对象可达性误判问题，如下图：假如对象 D对象被标记成黑色，E对象被标记为灰色（图左半部分），这时，工作线程将 E对象修改成不再指向F，并将 D对象指向 F对象（图右半部分），按照三色标记算法，D对象为黑色，不会再往下追溯，所以 F对象就无法被标记从而变成垃圾，“存活”对象凭空消失了，这是很可怕的问题，那么 CMS是如何解决这种问题的呢？

解决这种问题，通常有两种方案：

• 增量更新（Incremental Update）

当新增黑色对象指向白色对象关系时（D->F），需要记录这次新增，等并发扫描结束后，将这些黑色的对象作为 GC Root，重新扫描一次，也就是把这些黑色对象看成灰色对象，它们指向的白色对象就可以被正常标记。CMS采取的就是这种方式。

• 原始快照（Snapshot At The Beginning，SATB）

当删除灰色对象指向白色对象关系时（E->F），需要记录这次删除，等并发扫描结束后，将这些灰色的对象作为 GC Root，按照删除 E对象指向 F对象前一刻的快照（也就是E->F 还是可达的）重新扫描一次，即不管关系删除与否，都会按照删除前那一刻快照的对象图来进行搜索标记。G1，Shenandoah采取的是这种方式。

3.重新标记

重复标记阶段也会 Stop The World，即挂起所有的应用程序线程，该阶段主要完成事情是：

4.并发清除

这里的并发也是指应用线程和 GC线程可以并发执行，并发清除阶段主要完成 2个事情：

5.重置

清理和重置 CMS回收器的内部数据结构，为下一次垃圾回收做准备。

到此，回收过程就分析完毕，接下来总结下 CMS的优点和缺点。

CMS 的优点

低停顿时间

相对 Serial，Serial Old，ParNew，Parallel Scavenge 4款回收器，CMS收集器的主要优势是减少垃圾收集时的停顿时间，特别是减少了Full GC的停顿时间，这对于延迟敏感的应用程序非常有利。

并发收集

CMS在回收过程中，应用线程和 GC线程可以并发执行，从而减少了垃圾收集对应用程序的影响。

适合多核处理器

由于CMS利用了并发执行，它能够更好地利用现代多核处理器的能力，将垃圾收集的工作分散到多个CPU核心。

CMS 的缺点

浮动垃圾

在并发清除阶段，因为应用线程可以并发工作，可能会产生垃圾，这些垃圾在当前 GC无法处理，需要到下一次 GC才能进行处理，因此，这些垃圾就叫做“浮动垃圾”。

Concurrent Mode Failure

JDK5 默认设置下，当老年代使用了68%的空间后就会被激活 CMS回收，从JDK 6开始，垃圾回收启动阈值默认提升至92%，我们可以通过 -XX:CMSInitiatingOccupancyFraction 参数自行调节。

如果阈值是 68%，可能导致空间没有完全利用，频繁产生 GC，如果是92%，又会更容易面临另一种风险，要是预留的内存无法满足程序分配新对象的需要，就会出现一次 Concurrent Mode Failure（并发失败），因此会引发 FullGC。

这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。

内存碎片

因为 CMS采用的是标记-清理算法，当清理之后就会产生很多不连续的内存空间，这就叫做内存碎片。如果老年代无法使用连续空间来分配对象，就会出发 Full GC。为了解决这个问题，CMS收集器提供了 -XX：+UseCMS-CompactAtFullCollection 参数进行碎片压缩整理，参数默认是开启的，不过 从JDK 9开始废弃。

总结

• 本文不仅讲解了 CMS回收器，更是铺垫了很多 GC相关的基础知识，比如 安全点，三色标记法，卡表，写屏障。


• CMS 是 Concurrent Mark Sweep 的简称，中文翻译为并发标记清除，它的目标是减少垃圾回收时应用线程的停顿时间，并且实现应用线程和 GC线程并发执行。


• CMS 用于老年代的垃圾回收，使用的是标记-清除算法。通过 -XX:+UseConMarkSweepGC 参数即可启动 CMS收集器。


• CMS 主要包含：初始标记，并发标记，重新标记，并发清除，重置 5个过程。


• CMS 收集器使用三色标记法来标记对象，采用写屏障，卡表和脏页的方式来防止并发标记中修改的引用被漏标。


• CMS 收集器有 3大缺点：浮动垃圾，并发失败以及内存碎片。

尽管 CMS收集器已经被官方废弃了，但是它这种优化思路值得我们日常开发中借鉴。

希望文章可以给你带来收获和思考，如果有任何疑问，欢迎评论区留言讨论。如果本文对你有帮助，请帮忙点个在看，点个赞，或者转发给更多的小伙伴，获取三色标记法相关资料，请关注公众号，回复：三色

网站推荐

[CiteSeerX](citeseerx.ist.psu.edu)是一个公开的学术文献数字图书馆和搜索引擎，主要集中在计算机和信息科学领域的文献。该网站允许用户搜索、查看和下载相关的学术论文和文献，包括论文、会议记录、技术报告等。

CiteSeerX的特点包括：

• 自动引文索引：CiteSeerX使用算法自动从文档中提取引文，并创建文献之间的引用链接。


• 自动元数据提取：它能自动识别文档的元数据，如标题、作者、出版年份等。


• 相关文档推荐：根据用户的搜索和查看历史，CiteSeerX可以推荐相关的文档。


• 文档更新：CiteSeerX会自动在网络上查找和索引新文档，以保持数据库的更新。

CiteSeerX由宾夕法尼亚州立大学的信息科学与技术学院维护和管理。该项目是科研人员和学生获取计算机科学和相关学科文献的重要资源之一。

参考

HotSpot Virtual Machine Garbage Collection Tuning Guide

Java Garbage Collection Basics

Why does CMS collector collect root references from young generation on Initial Mark phase?

Memory Management in the Java HotSpot Virtual Machine

Why does Concurrent-Mark-Sweep (CMS) remark phase need to re-examine the thread-stacks instead of just looking at the mutator’s write-queues?

A Generational Mostly-concurrent Garbage Collector

The JVM Write Barrier - Card Marking

原创好文

• 9款常见的 JVM垃圾回收器


• 美团一面：Git 是如何工作的？(推荐阅读）


• 阿里 P7二面：Redis 执行 Lua，能保证原子性吗？


• 当下环境，程序员需要修炼的 3项技能


• AI是打工人的下一个就业风口吗?


• 和斯坦福博士写代码的一个月


• 肝了一周，这下彻底把 MySQL的锁搞懂了

7 年前，我被培训机构 8k 高薪的幌子，骗着带款了 2w 块钱，签完合同的后，我才觉察到自己被骗了。

但是 Java 好像挺有意思的，我学得不错，班里有 40 多个人，最后只有 3 个人找到了工作，我就是其中之一。

于是我入行了 Java，我的第一份工作在去哪儿，很感谢当年的领导给我面试机会，要知道当时我只有高中文凭，HR 反复确认要我来面试吗？我的领导说来试试吧。

为了那次面试，我推掉了所有其他面试，我对自己说一定要拿下这个 offer，在去面试的地铁上，我还在准备，我甚至准备了万一别人不要我，我可以做些什么来挽回。

后来面试通过了。

我珍惜这来之不易的机会，努力奋斗，晚上 10 点多下班是常态，有次冬天加到 12 点，我走在路上看着满大街的雪，反射出白光照向天空，亮亮的一点也不像晚上，我也一点都不冷。

那真是段美好的回忆，但是一年半后，压力太大，我主动提出了离职。

我跳槽到一家私企，工资翻了一倍，而且工作内容相比较之前，轻松的要死。除了基础代码开发，我顺手把服务器、Jenkins 部署、发布脚本、gitlab、redis、测试和线上环境全搭了。

但公司业务没做起来，部门解散了。

我接着找工作，年底通过了 thoughworks 的面试，和 HR 约定好了开年就发 offer 去上班，接到电话的时候我在图书馆，真是开心死了，现在回忆起来也不经咧开了嘴，爷也是能去外企的人了哈哈。

但是造化弄人，过年期间疫情来了，我的 offer 没了。

后来找到了一家创业公司，我和 boss 聊的很合拍，入职后工作了一年多，他和福禄建立了深度合作，把我带了过去。

截止至今，我在福禄工作了四年多，现在我面临着和 6 年前一样的问题，我对工作有了不一样的看法。

人们把工作当成一个赚钱的方式，出卖自己的时间换取经济价值。当然这没有问题，但我相信我的 boss，我感谢他知遇之恩，这些年我一直尽力多做一些事情。

只不过我的能力和认知，没有到那个境界，做的是很多，但也做错了很多，方法不对，成长也不够。

直到最近一次线上事故，我被击垮了。这是我五年来，第一次滋生离职的念头。

放下了对 boss “报恩” 的想法，我开始再次思考，工作的意义、生活的意义、人生的意义。

这不是我第一次思考，虽然我到现在也没找到答案。

曾经我的生活一眼望得到头，事业上，35 岁前努力工作存钱，35 后有了一定风险，但应该还能再工作几年，只要任劳任怨，万一真没公司要，再想别的出路，什么出路，我也不知道，生命总会找到出路。

生活中，20 多岁结婚，过几年生个娃，然后赚钱养家，天天为孩子奔波，把孩子养大，尽量给他好的环境。

身边的同事、朋友都是这样的，他们也劝我这样，不要想那些有的没的。

但是我忍不住会想，那我呢？我把时间给了工作、家庭、孩子，我在哪里？

有多少人真的了解自己？我不了解，我不知道自己喜欢什么，擅长什么，未来想做什么，想成为什么样的人。

我只是随大流，别人做什么，我也跟着做。买房、买车、结婚、生娃，这些人生重要节点，我做的那么随意。

痛苦让我成长，让我反思。如果回到 10 年前，我会对那时的自己这么说。

人生的重大决策，一定要仔细思考

买房

不要买房，不要背 30 年带款。这会把人压死，让人不敢尝试，不敢探索，失去勇气。

有个房贷压在头顶，那种窒息感和压力，无时无刻不在消耗自己。

做任何经济上有关的决策，都会忍不住想到我还有房贷呢。

会错失很多机会，也会让操作变形。

买车

车也是个消耗品，买车要钱，养车也要钱。停车费、过路费、油费、保养、车险，每年怎么也要大几千上万。

如果车带来的价值不如车的支出，我建议直接把房子租在公司附近，走路上下班，平时有事打车。

结婚

我之前从未思考过结婚意味着什么，也是随大流的和一个女孩子谈恋爱，谈了几年差不多了，就结婚了。

结婚意味着，和一个人共度余生。

这种影响未来几十年的决定，我甚至没认真思考过一天。

所以请一定要认真思考，可能即使我怎么说也不能理解，第一次结婚都没什么经验。

具体点说就是不要因为父母催婚去结婚；想清楚两个人之间的大方向上能不能统一；想清楚自己想从婚姻中获得什么，能提供什么价值；不要因为牛牛充血一时冲动；情绪化的选择，最终都会后悔，并付出惨重代价。

生娃

生娃那简直是比结婚更要命的存在。

以我现在的认知，我真的不理解为什么要生娃。

知乎上各种各样的答案，没一个能说服我，什么觉得生活没意思造个娃；夫妻生活不和谐靠娃调节等。

如果觉得生活没意思，夫妻没感情，那是自己的问题，生娃只是转移了问题，而不是解决问题。

所以我的态度是在没有想清楚为什么生娃之前，不生娃。

买车、买房、生娃，就算决定要做，我也建议晚点做，趁年轻先把事业打顺。

事业

刚进社会，懵懵懂懂啥都不知道，哪家公司给的钱多就去哪家。这是对的。

然后努力工作，不要躺平，多赚点钱，多存点钱。

工作了几年以后，兜里有点积蓄了，能覆盖两三年的支出，就要开始思考了。

这份工作有前途吗？我喜欢吗？对我个人有什么帮助？能学到什么知识？可不可以试试别的工作？

选择什么工作，入什么行业。这也是影响未来几十年的决策。

我觉得不要把工作看成出卖时间换取收入，那样会觉得自己在给别人打工，在给别人做事，心很累，做的事也不咋地。

应该把工作看成能力训练场、大型实验基地、资源交换中心；通过工作提升自己能力，让自己更值钱，通过公司验证个人的方法，学习经验，整理方法论。

把技能和经验学到一定程度，就可以结合手头积累的资源，自己创业了。

以学会赚钱为目的，为自己打工。

现在新能源和 AI 是公认的有前景的行业，往这两个方向靠。

现在我处在有点积蓄，准备尝试新的方向，去和钱比较近的岗位，学习赚钱能力，为以后创业赚钱打打基础。

寻找人生意义

我想有钱了再思考这个问题，被生活压的喘不过气的人，天天为生活奔波，哪有时间想这些呢？

在没有找到答案前，认真生活，对自己负责。

空闲时间刷抖音，打游戏，到处玩，偶尔放松可以理解，一直这样不行，这不叫认真生活。

当然这不怪当事人，我之前也是那样的，下班和周末看直播，刷短视频，搞学习什么，不存在的。

直到近期的变故，我深入思考这些问题，到处找课找人学习，认知有了提升，做这些事变得理所当然。

这种转变就像之前是强迫自己每天必须写篇文章，做复盘写总结，用意志力坚持，很痛苦，坚持不了多久。

现在是就是想写了，有感悟，想找个地方记录，主动的写，认真的写。

希望我的经历可以给各位参考，尽快提升认知，趁年轻，还有机会。

不要等有了车贷房贷，还有娃，但被裁了，或还没被裁但被当牛做马使劲压榨，而自身却没了任何反抗资本，才幡然醒悟，那样太残忍了些。

加油，共勉。

没错！95年，还剩几个月就奔三了。2024年，注定是人生中意义非凡的一年，忐忑、裁员、出书、求职、转正这几个词贯穿了一整年。

忐忑

在上一家公司时，我从面试开始和到入职半年转正后，其实内心对于公司的状况一直保持一种忐忑不安的心情，这种感觉跟我老婆说过几次，我们一致认为应当有心理准备。原因在于薪资与公司的组织架构、基础建设、日常工作量安排和人员扩充速度都让人感到迷惑。

公司是在一个包括高层话事人不断更换，高层（副总裁）突然接受停止调查；技术部门仅仅作为辅助，技术氛围低沉，基建缺失，直属leader作用甚微；工作量与人员匹配失常，人多活少，尽管如此年初还在不断扩招中，泡沫感极强，伴随着薪酬发放日漂浮不定，每到月底像是在开盲盒，你永远不知道银彳亍卡何时会有一笔款到账。

裁员

一系列薪酬制度改革和薪酬拖欠不得不怀疑高层战略的正确性，直到四月某一天CTO私聊我，泡沫破裂，裁员尘埃落定。

我被归属于第一批裁员名单中，与CTO交谈中，似乎也流露一丝对高层决策的不满，但没有明说，给我的理由是当前工作任务都很简单，匹配不了我的能力，所以给了我一个名额。

这放在当时听上去有些许意外，但我接受了这种措辞，并不是因为CTO说了几句好听的话，更多是我作为一个技术人的直觉认为这个CTO靠谱。离职过程中对人事提出的补偿计算方式以及分期发放，我都拒绝了，最后经过与人事反复讨论之后拿到了补偿，少不了他的协助，所以内心表示感谢。从现在的视角看来，似乎是他已经意料到公司的发展趋势，以致于后来被裁员的人有很大一部分都没有赔偿。

出书

离职后我在家休息了一个月，期间也为了帮一个粉丝忙，接手了他工作的一部分任务，主要是做游戏业务的动画。期间有被一个后端恶心到，业务不熟悉，接口一直不通就算了，关键还理直气壮说是前端问题；我佩服那个粉丝能够忍气吞声这么久，换做其他人也很难不高血压，为此特意发圈宣泄。

由于后端提供的接口迟迟不通，需求没有预期上线，为此他们老板还大发雷霆，最后把锅推给了这个前端粉丝，声称把他给炒了。没过一个月，粉丝的这个公司被帽子叔叔查封，业务涉及到了灰产，老板和负责人进去了。员工的工资都没发，但我的报酬是因为签了合约，在deadline之前要求他们打款，对我没有影响，这是苦了这个粉丝。

在此之后我便全职写书，《NestJS全栈开发解析：快速上手与实践》 这本书临近结尾，我一鼓作气完成了并在5.1号劳动节那天交稿；写书的想法也有一部分是来源于CTO的启发，后面图书审阅也是找了CTO帮忙，熬夜帮我看完并给了这个评语，为此我很感谢他。

经过几个月的审批和改稿，图书在9月份正式发布了各大平台，这是一件值得高兴的事情。

而对于前司的后续，据说后面还搬到一个CBD进行办公，但当时员工已经欠薪几个月，以至于到年底，公司被迫全员原地解散，很遗憾这不是一个好结果。

求职

交稿完成后，花了一个月左右时间求职，拿到了3个offer，最后选择了去深圳的美图，这是凭借NestJS的图书写作获得的一个岗位。之后由于组织架构变化，我在转正前夕面临选择继续从事Node全栈还是Go语言开发，考虑一番后我选择了后者，顺利转到了后端架构组，负责go语言开发，这对我来说又是一个新的尝试和挑战，我选择了这种变化，与框架和语言无关，只不过是践行我的人生哲学：【不断变化】，让自己处于一种长期乐观、短期痛苦、当下快乐的舒适区边缘中。

觉醒

关于成长，过去我一直不喜欢看历史，或许归根于上学时代对于历史学科的厌倦，没看过基本历史文献。2024年底，我看了教员的《毛选》、《实践论》、《矛盾论》、《寻乌调查》，第一种感受是成功绝不是偶然，环环相扣的逻辑能力令人惊叹。我想这些书籍回答了我一直以来的问题：

如何成为一个独立、深度思考的人？

我们人生中做了一个坏的决定，在股市中选择了不争气的股票，最坏的结果无非是让自己从头再来。但革命不同，选择错了就有可能让整个民族处于被毁灭的境地中，每一步都步履蹒跚，这该有怎样的智慧与思维？

第二种感受是遗憾没有早点开悟，在临近30岁时才开始阅读这些书籍，当然也很庆幸没有太晚，一切都来得及！

特别的是，《寻乌调查》报告里面的细节，应该是我人生中读过的一本最详细的一本书籍，里面还记载了寻乌与我老家（兴宁）相关的历史宜了，没有一句多余的，都是干货。第一次感受原来伟人离我这么近。

教员做了这个调查报告之后，便留下一句千古格言：没有调查，就没有发言权！反观自身，何尝不是应该这样呢？

关于家庭，今年整个过程中家里的大大小小的事基本上都是我老婆操办，为我们的小家默默付出了很多，加上我去了深圳之后，我的衣食住大部分也是她来打理，一个人照顾小孩，现在甜筒一岁半了，如我们所愿健康成长，这隶属她的功劳。

一个家庭要想变好，靠一个人努力不行，需要“拉拢”有能力的人一起，话事人脑子要清醒，能够明辨是非，唯唯诺诺绝对是会出问题的。

一个家族要想变好，靠一两个人不行，得靠一两个家庭真正向好，大家庭才会有希望。

最后，没有Flag，年度总结中对未来进行遐想没有意义，沉浸于自己完成所有Todo List的那种兴奋是虚构的，而实践中那种痛苦、无助才是我们最真实的感受，人不能总活在无限遐想的递归当中。

我看过那些在新年Flag列举诸多愿望，买了一堆书籍想要读完的，来年能真正落地完成的少之又少，毕竟我亦如此。

2025年，爱自己，爱家人，步步为营，不负将来！祝所有支持我的粉丝朋友们，一切如意，事业感情双丰收~

大家好，今天我想给你们介绍一个我最近发现的工具，叫 DeepSeek Engineer。它是一个专门为开发者打造的代码助手应用，可以帮你读文件、改文件，甚至生成代码。更厉害的是，它完全基于 DeepSeek API，能实时生成 JSON 格式的响应，让你的开发体验提升一个档次。

DeepSeek Engineer 是啥？

简单来说，DeepSeek Engineer 是一个基于命令行的智能助手。它能帮你完成这些事：

• 快速读文件内容：比如你有个配置文件，直接用命令把它加载进助手，后续所有操作都可以基于这个文件。


• 自动改文件：它不仅能提建议，还可以直接生成差异表（diff），甚至自动应用修改。


• 智能代码生成：比如你让它生成代码片段，它会按照指定格式和规则直接返回。

更重要的是，这一切都是通过 DeepSeek 的强大 API 来实现的。想象一下，你有个贴身助手，不仅能听懂你的代码需求，还能直接动手帮你写！

核心功能拆解

我们先来看 DeepSeek Engineer 的几个核心能力，让你更好地理解它的强大之处。

1. 自动配置 DeepSeek 客户端

启动这个工具时，你只需要准备一个 .env 文件，里面写上你的 API Key，比如：

DEEPSEEK_API_KEY=your_api_key_here

然后它会自动帮你连接到 DeepSeek 的服务器（地址通过环境变量配置）。接下来，所有的对话和操作都走这个 API，让你体验到类似 GPT 的流畅交互。

2. 数据模型：严格又灵活

DeepSeek Engineer 使用了 Pydantic 来定义和管理数据模型，这保证了所有操作都很安全且清晰。比如，它的模型包括以下几个部分：

• FileToCreate：描述新建或更新的文件。


• FileToEdit：定义某个文件里需要替换的代码片段。


• AssistantResponse：用来结构化处理助手返回的对话内容和文件操作。

具体来说，如果你想改文件内容，可以让它返回一个 JSON 格式的修改建议，类似这样：

{

  "file": "example.py",

  "changes": [

    {

      "original": "print('Hello')",

      "replacement": "print('Hello, DeepSeek!')"

    }

  ]

}

这种方式既直观又安全，你完全可以放心地应用这些修改。

3. 强大的系统 Prompt

DeepSeek Engineer 背后有一个设计得非常好的系统 Prompt，它会引导对话始终输出结构化的 JSON 数据，同时还能支持文件创建和编辑操作。

这个设计的好处是，开发者不用担心助手回复出错或格式混乱。所有的响应都像程序接口一样，清晰、标准。

4. 常用 Helper 函数

工具中还提供了一些实用的函数，专门用来操作文件和内容：

• read_local_file：快速读取本地文件内容，返回成字符串。


• create_file：帮你新建或覆盖文件。


• show_diff_table：生成一个漂亮的差异表，展示文件修改前后的对比。


• apply_diff_edit：直接应用代码片段级别的修改。

比如，你想更新一个文件里的某段代码，只需输入以下命令：

/add path/to/file

DeepSeek 会把这个文件的内容加载进来，你可以继续对话，让它生成修改建议并直接应用到文件中。

5. 交互式会话

运行主程序（比如 python3 main.py），你会进入一个交互式的命令行界面。这里你可以随时输入请求、加载文件，或者让助手生成代码。

完整操作流程可以是这样的：

是不是很贴心？

与其他工具的对比

市面上其实有不少类似的代码助手，比如 GitHub Copilot、TabNine 等。那么 DeepSeek Engineer 和它们相比有什么特别之处呢？我们通过下表来简单对比一下：

可以看出，DeepSeek Engineer 更加注重文件操作和开发流程的实际需求，非常适合需要精确控制和定制化的场景。

如何快速上手？

最后，说点大家最关心的：怎么用？

升级到 Java 21 是值得的

又到了一年中的这个时候——New Relic 的年度“State of the Java Ecosystem”调查结果出来了，我一如既往地深入研究了它。虽然我认为该报告做得很好并且提出了很好的问题，但我对有多少 Java 开发人员正在使用低版本感到沮丧。

您使用的是 Java 21 吗？确实应该使用了。

在开始调查之前，作为一名 Java 爱好者，我想谈谈我最喜欢的关于 Java 21 的一些事情。

首先我要说的是，Spring Boot 3.x 是当前 Java 虚拟机 (JVM) 上最流行的服务器端技术栈，至少需要 Java 17。它不支持 Java 8，这是第二个版本。根据调查，最常用的版本。

我很高兴看到 Java 17 的采用进展相对较快，但您确实应该使用 Java 21。Java 21 比 Java 8 好得多。它在所有方面都在技术上优越。它更快、更安全、更易于操作、性能更高、内存效率更高。

道德上也很优越。当您的孩子发现您在生产中使用 Java 8 时，您不会喜欢他们眼中流露出羞愧和悲伤的表情。

做正确的事，成为你希望在世界上看到的改变：使用 Java 21。它充满了优点，基本上是自 Java 7 以来的一种全新语言：Lambdas，Multiline strings。Smart switch expressions。 var 。Pattern matching。Named tuples（在 Java 中称为 records ）。

当然，最重要的是虚拟线程。虚拟线程是一件大事。它们提供了与 async / await 或 suspensions 相同的优点，但没有其他语言中冗长代码。

是的，你明白我的意思了。与其他语言相比，Java 的虚拟线程提供了更好的解决方案，并且代码更少。

如果你不知道我在说什么，并且使用其他语言，那么你现在会很生气。java？比您最喜欢的语言更简洁？不可能的！但我并没有错。

为什么虚拟线程很重要

要了解virtual threads，您需要了解创建它们是为了解决的问题。如果您还没有体验过虚拟线程，那么它们有点难以描述。我会尽力。

Java 有阻塞操作——比如 Thread.sleep(long) 、 InputStream.read 和 OutputStream.write 。如果您调用其中一个方法，程序将不会前进到下一行，直到这些方法完成它们正在做的事情并返回。

大多数网络服务都是 I/O 密集的，这意味着它们将大部分时间花在输入和输出方法上，例如 InputStream.read 和 OutputStream.write 。

任务提交到线程池中却没有更多线程的服务是很常见的，但仍然无法返回响应，因为所有现有线程都在等待某些 I/O 操作发生，例如跨线程的 I/O HTTP 边界、数据库或消息队列的 I/O。

有多种方法可以解锁 I/O。您可以使用 java.nio ，它非常复杂，会引起焦虑。您可以使用reactive式编程，它的工作原理是范式的(paradigmatically)，但它是对整个代码库的完整重构。

因此，我们的想法是：如果编译器知道您何时执行了可能会阻塞的操作（例如 InputStream.read ）并重新排序代码的执行，这不是很好吗？因此，当您执行阻塞操作时，等待代码将从当前执行线程移出，直到阻塞操作完成，然后在准备好恢复执行后将其放回另一个线程。

这样，您就可以继续使用阻塞语义。第一行在第二行之前执行。这提高了可调试性和可扩展性。您不再垄断线程只是为了在等待某些事情完成时浪费它们。这将是两全其美：非阻塞 I/O 的可扩展性与更简单的阻塞 I/O 的明显简单性、可调试性和可维护性。

许多其他语言，如 Rust、Python、C#、TypeScript 和 JavaScript，都支持 async / await 。 Kotlin 支持 suspend 。这些关键字提示运行时您将要做一些阻塞的事情，并且它应该重新排序执行。这是一个 JavaScript 示例：

async function getCustomer(){ /* call a database */ }

const result = await getCustomer();

问题症结在于要调用 async 函数，还必须位于 async 函数中：

async function getCustomer(){ /* call a database */ }



async function main(){ 

  const result = await getCustomer();

}

async 关键字 是病毒式的。它蔓延开来。最终，你的代码会陷入 async / await 的泥潭——你为什么在任何可能的地方使用async/await呢？因为，它比使用低级、非阻塞 I/O 或反应式编程要好，但也只是勉强好。

Java 提供了一种更好的方法。只需为您的线程使用不同的工厂方法即可。

如果您使用 ExecutorService 创建新线程，请使用创建虚拟线程的新版本。

var es = Executors.newVirtualThreadPerTaskExecutor(); 

// ^- this is different and you'll probably only do it once 

// or twice in a typical application

var future = es.submit(() -> System.out.println("hello, virtual threads!"));

如果您直接在较低级别创建线程，则使用新的工厂方法：

// this is different

var thread = Thread.ofVirtual().start(() -> System.out.println("hello, virtual threads!"));

您的大部分代码保持完全不变，但现在您的可扩展性得到了显着提高。如果您创建数百万个线程，运行时不会喘息。我无法预测您的结果会是什么，但您很有可能不再需要运行给定服务的几乎同样多的实例来处理负载。

如果您使用的是 Spring Boot 3.2（您是，不是吗？），那么您甚至不需要执行任何操作。只需在 application.properties 中指定 spring.threads.virtual.enabled=true ，然后向管理层请求加薪，费用由大幅降低的云基础设施成本支付。

并非每个应用程序都可以在技术上实现跨越，但其中绝大多数可以而且应该。

使用情况报告分析

最后，这让我回到了 New Relic 报告。不要误会我的意思：它做得非常好，值得一读。就像莎士比亚悲剧一样，它写得很好，讲述了一个悲伤的故事。

有一个完整的部分证实了显而易见的事实：天空是蓝色的，云彩无处不在。在容器中部署工作负载似乎是主流模式，受访者表示 70% 的 Java 工作负载使用容器。坦白说，我很惊讶它这么低。

同样令人感兴趣的是从单核配置转向多核的趋势。根据调查，30% 的容器化应用程序正在使用 Java 9 的 -XX:MaxRAMPercentage 标志，该标志限制了 RAM 使用。 G1 是最流行的垃圾收集器。一切都很好。

当涉及到 Java 版本时，该报告发生了悲剧性的转变。超过一半的应用程序（56%）在生产中使用 Java 11，而 2022 年这一比例为 48%。Java 8（十年前的 2014 年发布）紧随其后，近 33% 的应用程序在生产中使用它。根据调查，三分之一的应用程序仍在使用 Java 版本，该版本在《Flappy Bird》游戏被下架、《冰桶挑战》横扫 Vine、《Ellen DeGeneres 奥斯卡》自拍照火爆的同一年推出。

多个用户使用 Amazon 的 OpenJDK 分发版。该报告表明，这是因为甲骨文暂时为其发行引入了更严格的许可。但我想知道其中有多少只是 Amazon Web Services（最多产的基础设施即服务 (IaaS) 供应商）上 Java 工作负载默认分布的函数。自几年前推出以来，该发行版已受到广泛欢迎。 2020年，它的市场份额为2.18%，现在则为31%。如果这么多人可以如此迅速地迁移到完全不同的发行版，那么他们应该能够使用同一发行版的新版本，不是吗？

我想，趋势中还是有一些希望的。 Java 17 用户采用率一年内增长了 430%。因此，也许我们会在 Java 21 中看到类似的数字——Java 21 已经全面发布近六个月了。

你还在等什么？

正如我在 Voxxed Days 的演讲中所说，我相信现在是成为 Java 和 Spring Boot 开发人员的最佳时机。 Java 和 Spring 开发人员拥有最好的玩具。我什至还没有提到 GraalVM 本机映像，它可以显着缩短给定 Java 应用程序的启动时间并减少内存占用。这已经与 Java 21 完美配合。

这些东西就在这里，它们太棒了。能否实现这一跳跃取决于我们。这并不难。试试看。

安装 SDKMan，运行 sdk install java 21.0.2-graalce 然后运行 ​​ sdk default java 21.0.2-graalce 。这将为您提供 Java 21 和 GraalVM 本机映像编译器。访问 Spring Initializr，这是我在网络上第二喜欢的地方（仅次于生产），网址为 start.spring.io。配置一个新项目。选择 Java 21（自然！）。添加 GraalVM Native Support 。添加 Web 。点击 Generate 按钮并将其加载到您的 IDE 中。在 application.properties 中指定 spring.threads.virtual.enabled=true 。创建一个简单的 HTTP 控制器：

@Controller

class Greetings {



 @GetMapping("/hi")

 String hello(){ 

    return "hello, Java 21!";

 }

}

将其编译为 GraalVM 本机映像： ./gradlew nativeCompile 。运行 build 文件夹中的二进制文件。

现在，您已经有了一个应用程序，该应用程序只占用非 GraalVM 本机映像所需 RAM 的一小部分，并且还能够扩展到每秒更多的请求。简单，而且令人惊奇。

原文地址:We CAN Have Nice Things: Upgrading to Java 21 Is Worth It - The New Stack

0. 引入

Spring Boot 以其简化配置、快速开发和微服务支持等特点，成为了 Java 开发的首选框架。本文将结合我在实际工作中遇到的问题，分享五个高效的 Spring Boot 的技巧。希望这些技巧能对你有所帮助。

1. Spring Boot 执行初始化逻辑

1.1 背景

项目的某次更新，数据库中的某张表新增了一个字段，且与业务有关联，需要对新建的字段根据对应的业务进行赋值操作。

一种解决方案就是，更新前手动写 SQL 更新字段的值，但这样做的效率太低，而且每给不同环境更新一次，就需要手动执行一次，容易出错且效率低。

另一种方案则是在项目启动时进行初始化操作，完成字段对应值的更新，这种方案效率更高且不容易出错。

1.2 实现

Spring Boot 提供了多种方案用于项目启动后执行初始化的逻辑。

• 实现CommandLineRunner接口，重写run方法。

@Slf4j

@Component

public class InitListen implements CommandLineRunner {



    @Override

    public void run(String... args) {

      // 初始化相关逻辑...

    }





}

• 实现ApplicationRunner接口，重写run方法。

@Slf4j

@Component

public class InitListen implements ApplicationRunner {



    @Override

    public void run(ApplicationArguments args) {

      // 初始化相关逻辑...

    }





}

• 实现ApplicationListener接口

@Slf4j

@Configuration

public class StartClientListener implements ApplicationListener<ContextRefreshedEvent> {



    @Override

    public void onApplicationEvent(ContextRefreshedEvent arg0) {

        // 初始化逻辑

    }

}

针对于上述这个需求，如何实现仅更新一次字段的值？

可在数据库字典表中设置一个更新标识字段，每次执行初始化逻辑之前，校验判断下字典中的这个值，确认是否已经更新，如果已经更新，就不需要再执行更新操作了。

2. Spring Boot 动态控制数据源的加载

2.1 背景

期望通过在application.yml文件中，添加一个开关来控制是否加载数据库。

2.2 实现

启动类上添加注解 @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })，代表禁止 Spring Boot 自动注入数据源。

新建 DataSourceConfig配置类，用于初始化数据源。

在DataSourceConfig配置类上添加条件注解 @ConditionalOnProperty(name = "spring.datasource.enabled", havingValue = "true"，代表只有当 spring.datasource.enabled 为 true时，加载数据库，其余情况不加载数据库。

仓库类 XxxRepository 的注入，需要使用注解 @Autowired(required = false)

详细可见文章：
Spring Boot 如何动态配置数据库的加载

3. Spring Boot 根据不同环境加载配置文件

3.1 背景

实际开发工作中，针对同一个项目，可能会存在开发环境、测试环境、正式环境等，不同环境的配置内容可能会不一致，如：数据库、Redis等等。期望在项目在启动时能够针对不同的环境来加载不同的配置文件。

3.2 实现

Spring 提供 Profiles 特性，通过启动时设置指令-Dspring.profiles.active指定加载的配置文件，同一个配置文件中不同的配置使用---来区分。

启动 jar 包时执行命令：

java -jar test.jar -Dspring.profiles.active=dev

-Dspring.profiles.active=dev代表激活 profiles 为 dev 的相关配置。

## 用---区分环境，不同环境获取不同配置

---

# 开发环境

spring:

  profiles: dev

  cloud:

    nacos:

      discovery:

        server-addr: 127.0.0.1:8848

        # 命名空间为默认，所以不需要写命名空间

      config:

        server-addr: ${spring.cloud.nacos.discovery.server-addr}

        extension-configs[0]:

          data-id: database-base.yaml

          group: DEFAULT_GR0UP

          refresh: true

        extension-configs[1]:

          # 本地单机Redis

          data-id: redis-base-auth.yaml

          group: DEFAULT_GR0UP

          refresh: true

        extension-configs[2]:

          data-id: master-base-auth.yaml

          group: DEFAULT_GR0UP

          refresh: true

---

#测试环境

spring:

  profiles: test

  cloud:

    nacos:

      discovery:

        server-addr: 192.168.0.111:8904

        # 测试环境注册的命名空间

        namespace: b80b921d-cd74-4f22-8025-333d9b3d0e1d

      config:

        server-addr: ${spring.cloud.nacos.discovery.server-addr}

        extension-configs[0]:

          data-id: database-base-test.yaml

          group: DEFAULT_GR0UP

          refresh: true

        extension-configs[1]:

          data-id: redis-base-test.yaml

          group: DEFAULT_GR0UP

          refresh: true

        extension-configs[2]:

          data-id: master-auth-test.yaml

          group: DEFAULT_GR0UP

          refresh: true



---

# 生产环境

spring:

  profiles: prod

  cloud:

    nacos:

      discovery:

        server-addr: 192.168.0.112:8848

      config:

        server-addr: ${spring.cloud.nacos.discovery.server-addr}

        extension-configs[0]:

          # 生产环境

          data-id: database-auth.yaml

          group: DEFAULT_GR0UP

          refresh: true

        extension-configs[1]:

          # 生产环境

          data-id: redis-base-auth.yaml

          group: DEFAULT_GR0UP

          refresh: true

        extension-configs[2]:

          data-id: master-base-auth.yaml

          group: DEFAULT_GR0UP

          refresh: true

也可以定义多个配置文件，如在application.yml中定义和环境无关的配置，而application-{profile}.yml则根据环境做不同区分，如在 application-dev.yml 中定义开发环境相关配置、application-test.yml 中定义测试环境相关配置。

启动时指定环境命令同上，仍为：

java -jar test.jar -Dspring.profiles.active=dev

4. Spring Boot 配置文件加密

4.1 背景

配置文件中包含的敏感信息（如数据库密码）都会以明文的形式存储，这种情况可能会存在安全风险，期望通过加密配置文件，确保应用程序的安全。

4.2 实现

• pom.xml 文件中引入依赖。

<dependency>

   <groupId>com.github.ulisesbocchio</groupId>

   <artifactId>jasypt-spring-boot-starter</artifactId>

   <version>2.1.2</version>

</dependency>

如果遇到 Unresolved dependency: 'com.github.ulisesbocchio:jasypt-spring-boot-starter:jar:2.1.2' 的错误，可执行mvn clean install -U强制更新依赖。

• application.yml 文件中增加配置如下：

jasypt:

  encryptor:

    password: G0C3D17o2n6

    algorithm: PBEWithMD5AndDES

• 执行测试用例，获取加密后的内容。

@RunWith(SpringRunner.class)

@SpringBootTest

public class DatabaseTest {



    @Autowired

    private StringEncryptor encryptor;



    @Test

    public void getPass() {

        String url = encryptor.encrypt("jdbc:mysql://localhost:3306/demo");

        String name = encryptor.encrypt("root");

        String password = encryptor.encrypt("123456");

        System.out.println("database url: " + url);

        System.out.println("database name: " + name);

        System.out.println("database password: " + password);

        Assert.assertTrue(url.length() > 0);

        Assert.assertTrue(name.length() > 0);

        Assert.assertTrue(password.length() > 0);

    }

}

根据测试用例获取的结果，将加密后的字符串替换明文。

• 启动程序，验证数据库能否正常连接。

为了防止 jasypt.encryptor.password 泄露，反解出密码，有两种方案：

• 将 jasypt.encryptor.password 设置为环境变量，如：

vim /etc/profile

export jasypt.encryptor.password=YOUR_SECRET_KEY

• 将 jasypt.encryptor.password 作为启动程序的参数，如：

java -jar xxx.jar -Djasypt.encryptor.password=YOUR_SECRET_KEY

5. Spring Boot对打包好的jar包瘦身

5.1 背景

Sprng Boot项目的 jar 包动辄几百MB，如果有小的需求更新或者是Bug修复，就需要重新打包部署，改了一行代码，却上传几百MB的文件，这样会很浪费时间。

期望通过给 jar 包瘦身，从而节省部署的时间。

5.2 实现

• pom.xml 文件中添加如下配置：

<build>

  <plugins>

   <plugin>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-maven-plugin</artifactId>

    <configuration>

     <executable>true</executable>

     <layout>ZIP</layout>

     <!--这里是填写需要包含进去的jar，

          必须项目中的某些模块，会经常变动，那么就应该将其坐标写进来

          如果没有则nothing ，表示不打包依赖 -->

     <includes>

      <include>

       <groupId>nothing</groupId>

       <artifactId>nothing</artifactId>

      </include>

     </includes>

    </configuration>

   </plugin>



   <!--拷贝依赖到jar外面的lib目录-->

   <plugin>

    <groupId>org.apache.maven.plugins</groupId>

    <artifactId>maven-dependency-plugin</artifactId>

    <executions>

     <execution>

      <id>copy</id>

      <phase>package</phase>

      <goals>

       <goal>copy-dependencies</goal>

      </goals>

      <configuration>

       <!--指定的依赖路径-->

       <outputDirectory>

        ${project.build.directory}/lib

       </outputDirectory>

      </configuration>

     </execution>

    </executions>

   </plugin>

  </plugins>

 </build>

• 执行mvn clean package得到 jar 包，在项目启动时，需要通过 -Dloader.path指定lib的路径，如：

java -Dloader.path=./lib -jar testProject-0.0.1-SNAPSHOT.jar

效果如下：

通过分析 jar 包的结构可以得知，jar 包的 “大” 实际上是因为在打包时，会将项目所依赖的 jar 包放在 lib 夹文件中。而这部分依赖在版本迭代稳定后，基本是不会变化的。

上述这种给 jar 包瘦身的方案，实际上是在打包的时候忽略 lib 文件夹中的这些依赖，将这部分不变的依赖提前放到服务器上，打出来的 jar 包就变小了，从而提升发版效率。

参考资料

zhuanlan.zhihu.com/p/646593227

cloud.tencent.com/developer/a…

interface NetApi {



    // 示例get 请求

    @GET("https://www.wanandroid.com/article/list/0/json")

    suspend fun getHomeList(): CommonResult



    // 示例get 请求2

    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList(@Path("path") page: Int): CommonResult



    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList(@Path("path") page: Int, @Path("path") a: Int): CommonResult



    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList(@Path("path") page: Int, @Path("path") f: Float): CommonResult



    // 示例get 请求2

    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList2222(@Path("path") page: Int): CommonResult



    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList3333(@Path("path") page: Int): CommonResult



    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList5555(@Path("path") page: Int, @Query("d") ss: String, @HeaderMap map: Map): CommonResult



    @GET("https://www.wanandroid.com/article/list/{path}/json")

    suspend fun getHomeList6666(

        @Path("path") page: Int,

        @Query("d") float: Float,

        @Query("d") long: Long,

        @Query("d") double: Double,

        @Query("d") byte: Byte,

        @Query("d") short: Short,

        @Query("d") char: Char,

        @Query("d") boolean: Boolean,

        @Query("d") string: String,

        @Body body: RequestBodyWrapper

    ): CommonResult

    

    //示例post 请求

    @FormUrlEncoded

    @POST("https://www.wanandroid.com/user/register")

    suspend fun register(

        @Field("username") username: String,

        @Field("password") password: String,

        @Field("repassword") repassword: String

    ): String

    /************************* 以下只 示例写法，接口调不通，因为找不到那么多 公开接口  全是 Retrofit的用法 来测试 *****************************************************/





//    @FormUrlEncoded

    @Headers("Content-Type: application/x-www-form-urlencoded")  //todo 固定 header

    @POST("https://xxxxxxx")

    suspend fun post1(@Body body: RequestBody): String



    //    @FormUrlEncoded

    @Headers("Content-Type: application/x-www-form-urlencoded")

    @POST("https://xxxxxxx22222")

    suspend fun post12(@Body body: RequestBody, @HeaderMap map: Map): String //todo  HeaderMap 多个请求头部自己填写



    suspend fun post1222(@Body body: RequestBody, @HeaderMap map: Map): String //todo  HeaderMap 多个请求头部自己填写

}

class NetRepository private constructor() {

    val service by lazy { RetrofitUtils.instance.create(NetApi::class.java) }



    companion object {

        val instance by lazy { NetRepository() }

    }



    // 示例get 请求

    fun getHomeList() = flow { emit(service.getHomeList()) }



    // 示例get 请求2

    fun getHomeList(page: Int) = flow { emit(service.getHomeList(page)) }



    fun getHomeList(page: Int, a: Int) = flow { emit(service.getHomeList(page, a)) }



    fun getHomeList(page: Int, f: Float) = flow { emit(service.getHomeList(page, f)) }



    // 示例get 请求2

    fun getHomeList2222(page: Int) = flow { emit(service.getHomeList2222(page)) }



    fun getHomeList3333(page: Int) = flow { emit(service.getHomeList3333(page)) }



    fun getHomeList5555(page: Int, ss: String, map: Map<String, String>) = flow { emit(service.getHomeList5555(page, ss, map)) }



    fun getHomeList6666(

        page: Int, float: Float, long: Long, double: Double, byte: Byte,

        short: Short, char: Char, boolean: Boolean, string: String, body: RequestBodyWrapper

    ) = flow {

        emit(service.getHomeList6666(page, float, long, double, byte, short, char, boolean, string, body))

    }



    fun register(username: String, password: String, repassword: String) = flow { emit(service.register(username, password, repassword)) }



    //

//    /************************* 以下只 示例写法，接口调不通，因为找不到那么多 公开接口  全是 Retrofit的用法 来测试 *****************************************************/

//

//

    fun post1(body: RequestBody) = flow { emit(service.post1(body)) }



    fun post12(body: RequestBody, map: Map<String, String>) = flow { emit(service.post12(body, map)) }



    fun post1222(id: Long, asr: String) = flow {

        val map = mutableMapOf()

        map["id"] = id

        map["asr"] = asr

        val mapHeader = HashMap()

        mapHeader["v"] = 1000

        mapHeader["device_sn"] = "Avidfasfa1213"

        emit(service.post1222(RequestBodyWrapper(Gson().toJson(map)), mapHeader))

    }

}

class MainViewModel : BaseViewModel() {



    private val repository by lazy { NetRepository.instance }



    fun getHomeList(page: Int) {

        flowAsyncWorkOnViewModelScopeLaunch {

            repository.getHomeList(page).onEach {

                android.util.Log.e("MainViewModel", "one 111 ${it.data?.datas!![0].title}")

            }

        }

    }

}

三、花式封装（二）

 5. viewModel调用端

class MainViewModel : BaseViewModel() {



    private val repository by lazy { RNetApiRepository() }



    fun getHomeList(page: Int) {

        flowAsyncWorkOnViewModelScopeLaunch {

            val time = System.currentTimeMillis()

            repository.getHomeList(page).onEach {

                android.util.Log.e("MainViewModel", "two 222 ${it.data?.datas!![0].title}")

                android.util.Log.e("MainViewModel", "耗时:${(System.currentTimeMillis() - time)} ms")

            }

        }

    }

}

6. 如果 Repository 中某个接口方法需要特殊处理怎么办？比如下图，请求前处理一下，从 拿到数据后我需要再次转化处理之后再给到 viewModel 怎么办？

//我这个接口 ，请求前需要 判断处理一下，拿到数据后也需要再处理一下

fun post333(id: Long, asr: String, m: String, n: String, list: List<String>) = flow {

    val map = mutableMapOf()

    map["id"] = id

    map["asr"] = asr

    val mapHeader = HashMap()

    mapHeader["v"] = 1000

    mapHeader["device_sn"] = "Avidfasfa1213"



    //接口调用前 根据 需要处理操作

    list.forEach {

        if (map.containsKey(id.toString())) {

            ///

        }

    }



    val result = service.post1222(RequestBodyWrapper(Gson().toJson(map)), mapHeader)

    // 拿到数据后需要处理操作

    val result1 = result

    emit(result1)

}.map {

    //需要再转化一下

    it

}.filter {

    //过滤一下

    it.length == 3

}

7. 可以在 接口 NetApi 中该方法上配置 @Filter 注解过滤 ，该方法需要自己特殊处理，不自动生成，如下

@Filter

@POST("https://xxxxxxx22222")

suspend fun post333(@Body body: RequestBody, @HeaderMap map: Map): String

8. 如果想 post请求的 RequestBody 内部参数单独出来进入方法传参，可以加上 在 NetApi 中方法加上 @PostBody：如下：

@PostBody("{"ID":"Long","name":"String"}")

@POST("https://www.wanandroid.com/user/register")

suspend fun testPostBody222(@Body body: RequestBody): String

这样 该方法生成出来的对应方法就是：

public suspend fun testPostBody222(ID: Long, name: java.lang.String): Flow =

    kotlinx.coroutines.flow.flow {

        val map = mutableMapOf()

        map["ID"] = ID

        map["name"] = name

        val result = service.testPostBody222(com.wx.test.api.retrofit.RequestBodyCreate.toBody(com.google.gson.Gson().toJson(map)))

        emit(result)

    }

怎么特殊处理，单独手动建一个Repository,针对该方法，单独写，特殊就要特殊手动处理，但是大多数模版式的代码，都可以让其自动生成。

—————————————————我是分割线君—————————————————

到了这里，我们再想， NetApi 是一个接口类，
但是实际上没有写接口实现类啊， 它怎么实现的呢？
我们上面 花式玩法（二） 中虽然是自动生成的，但是还是有方法体，

可不可以再省略点？

可以，必须有！

四、花式玩法（三）

@AutoCreateRepositoryInterface(interfaceApi = "com.wx.test.api.net.NetApi")

class KaptInterface {

}

生成的接口类 INetApiRepository 代码如下：

public interface INetApiRepository {

  public fun getHomeList(): Flow>



  public fun getHomeList(page: Int): Flow>



  public fun getHomeList(page: Int, f: Float): Flow>



  public fun getHomeList(page: Int, a: Int): Flow>



  public fun getHomeList2222(page: Int): Flow>



  public fun getHomeList3333(page: Int): Flow>



  public fun getHomeList5555(

      page: Int,

      ss: String,

      map: Map<String, String>

  ): Flow>



  public fun getHomeList6666(

      page: Int,

      float: Float,

      long: Long,

      double: Double,

      byte: Byte,

      short: Short,

      char: Char,

      boolean: Boolean,

      string: String,

      body: RequestBodyWrapper

  ): Flow>



  public fun getHomeListA(page: Int): Flow>



  public fun getHomeListB(page: Int): Flow



  public fun post1(body: RequestBody): Flow



  public fun post12(body: RequestBody, map: Map<String, String>): Flow



  public fun post1222(body: RequestBody, map: Map<String, Any>): Flow



  public fun register(

      username: String,

      password: String,

      repassword: String

  ): Flow



  public fun testPostBody222(ID: Long, name: java.lang.String): Flow

}

3. Repository 职责承担的调用端：用动态代理：

class RepositoryPoxy private constructor() : BaseRepositoryProxy() {



    val service = NetApi::class.java

    val api by lazy { RetrofitUtils.instance.create(service) }





    companion object {

        val instance by lazy { RepositoryPoxy() }

    }



    fun  callApiMethod(serviceR: Class<R>): R {

        return Proxy.newProxyInstance(serviceR.classLoader, arrayOf(serviceR)) { proxy, method, args ->

            flow {

                val funcds = findSuspendMethod(service, method.name, args)

                if (args == null) {

                    emit(funcds?.callSuspend(api))

                } else {

                    emit(funcds?.callSuspend(api, *args))

                }

//                emit((service.getMethod(method.name, *parameterTypes)?.invoke(api, *(args ?: emptyArray())) as Call).execute().body())

            }.catch {

                if (it is InvocationTargetException) {

                    throw Throwable(it.targetException)

                } else {

                    it.printStackTrace()

                    throw it

                }

            }

        } as R

    }

}

4. BaseRepositoryProxy 中内容：

open class BaseRepositoryProxy {



    private val map by lazy { mutableMapOf?>() }

    private val sb by lazy { StringBuffer() }



    @OptIn(ExperimentalStdlibApi::class)

    fun  findSuspendMethod(service: Class<T>, methodName: String, args: Array<out Any>): KFunction<*>? {

        sb.delete(0, sb.length)

        sb.append(service.name)

            .append(methodName)

        args.forEach {

            sb.append(it.javaClass.typeName)

        }

        val key = sb.toString()

        if (!map.containsKey(key)) {

            val function = service.kotlin.memberFunctions.find { f ->

                var isRight = 0

                if (f.name == methodName && f.isSuspend) {

                    if (args.size == 0 && f.parameters.size == 1) {

                        isRight = 2

                    } else {

                        f.parameters.forEachIndexed { index, it ->

                            if (index > 0 && args.size > 0) {

                                if (args.size == 0) {

                                    isRight = 2

                                    return@forEachIndexed

                                }

                                if (it.type.javaType.typeName == javaClassTransform(args[index - 1].javaClass).typeName) {

                                    isRight = 2

                                } else {

                                    isRight = 1

                                    return@forEachIndexed

                                }

                            }

                        }

                    }

                }

                //方法名一直  是挂起函数  方法参数个数一致， 参数类型一致

                f.name == methodName && f.isSuspend && f.parameters.size - 1 == args.size && isRight == 2

            }

            map[key] = function

        }

        return map[key]

    }



    private fun javaClassTransform(clazz: Class<Any>) = when (clazz.typeName) {

        "java.lang.Integer" -> Int::class.java

        "java.lang.String" -> String::class.java

        "java.lang.Float" -> Float::class.java

        "java.lang.Long" -> Long::class.java

        "java.lang.Boolean" -> Boolean::class.java

        "java.lang.Double" -> Double::class.java

        "java.lang.Byte" -> Byte::class.java

        "java.lang.Short" -> Short::class.java

        "java.lang.Character" -> Char::class.java

        "SingletonMap" -> Map::class.java

        "LinkedHashMap" -> MutableMap::class.java

        "HashMap" -> HashMap::class.java

        "Part" -> MultipartBody.Part::class.java

        "RequestBody" -> RequestBody::class.java

        else -> {

            if ("RequestBody" == clazz.superclass.simpleName) {

                RequestBody::class.java

            } else {

                Any::class.java

            }

        }

    }

}

5. ViewModel中调用端：

class MainViewModel : BaseViewModel() {



    private val repository by lazy { RepositoryPoxy.instance }



    fun getHomeList(page: Int) {

        flowAsyncWorkOnViewModelScopeLaunch {

            val time = System.currentTimeMillis()

            repository.callApiMethod(INetApiRepository::class.java).getHomeList(page).onEach {

                android.util.Log.e("MainViewModel", "three 333 ${it.data?.datas!![0].title}")

                android.util.Log.e("MainViewModel", "耗时:${(System.currentTimeMillis() - time)} ms")

            }

        }

    }

}

—————————————————我是分割线君—————————————————

6. 上面生成的接口类 INetApiRepository 其实方法和 NetApi 拥有相似的模版，唯一区别就是返回类型，一个是对象，一个是Flow 流的对象

   还能省略吗？

   有，必须有

五、花式玩法（四）

class RepositoryPoxy private constructor() : BaseRepositoryProxy() {



 val service = NetApi::class.java

 val api by lazy { RetrofitUtils.instance.create(service) }





 companion object {

     val instance by lazy { RepositoryPoxy() }

 }



 fun  callApiMethod(clazzR: Class<R>, methodName: String, vararg args: Any): Flow {

     return flow {

         val clssss = mutableListOfout Any>>()

         args?.forEach {

             clssss.add(javaClassTransform(it.javaClass))

         }

         val parameterTypes = clssss.toTypedArray()

         val call = (service.getMethod(methodName, *parameterTypes)?.invoke(api, *(args ?: emptyArray())) as Call)

         call?.execute()?.body()?.let {

             emit(it as R)

         }

     }

 }



 @OptIn(ExperimentalStdlibApi::class)

 fun  callApiSuspendMethod(clazzR: Class<R>, methodName: String, vararg args: Any): Flow {

     return flow {

         val funcds = findSuspendMethod(service, methodName, args)

         if (args == null) {

             emit(funcds?.callSuspend(api) as R)

         } else {

             emit(funcds?.callSuspend(api, *args) as R)

         }

     }

 }

}

2. ViewModel中调用入下：

class MainViewModel : BaseViewModel() {



    private val repository by lazy { RepositoryPoxy.instance }



    fun getHomeList(page: Int) {

        flowAsyncWorkOnViewModelScopeLaunch {

            val time = System.currentTimeMillis()

            repository.callApiSuspendMethod(HomeData::class.java, "getHomeListB", page).onEach {

                android.util.Log.e("MainViewModel", "four 444 ${it.data?.datas!![0].title}")

                android.util.Log.e("MainViewModel", "耗时:${(System.currentTimeMillis() - time)} ms")

            }

        }

    }

}

六、总结

通过上面4中花式玩法:

项目地址

项目地址：
github地址
gitee地址

感谢阅读：

欢迎 点赞、收藏、关注

前言

标题党了，原生go很好用，只不过我习惯了java封装大法。最近在看golang，因为是javaer，所以突发奇想，不如开发一个类似于 Maven 或 Gradle 的构建工具来管理 Go 项目的依赖，众所周知，构建和发布是一个复杂的任务，但通过合理的设计和利用现有的工具与库，可以实现一个功能强大且灵活的工具。

正文分为两部分：项目本身和如何使用

一、项目本身

1. 项目需求分析

核心需求