<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[yang11qiang的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/yang11qiang</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; yang11qiang]]></copyright><item><title><![CDATA[spring cache 的扩展封装 （小项目用）]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/146015636</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/146015636</guid><author>yang11qiang</author><pubDate>Wed, 05 Mar 2025 15:21:49 +0800</pubDate><description><![CDATA[expireTime = 30000, // 30秒动态过期，这个只能配合 @CacheabledelayDeleteTime = 5000, // 5秒延迟双删, 这个只能配合 @CacheEvictlockWhenQuery = true //默认值改为false就是使用spring默认的锁aop拦截该注解，使用ThreadLocal维护CacheExtensionContext上下文重写CustomRedisCache在put操作时动态读取过期时间，然后修改核心方法设置过期时间。]]></description><category></category></item><item><title><![CDATA[一个小功能的改造，结果到处都是redis的身影]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/140547666</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/140547666</guid><author>yang11qiang</author><pubDate>Sat, 20 Jul 2024 22:19:57 +0800</pubDate><description><![CDATA[然后在redis中记录每个节点的 ip 和 端口，以及每个节点完成的任务情况，当前节点全部任务结束后就去检查下是否每个节点都完成，比如设置等待30秒超时，节点完成任务就每5秒循环一次看下是不是所有节点都完成了任务，直到所有节点已完成或者已下线或者到了超时时间，就再用redis做个标记，记录当前节点已发送消息，其他节点发送前判断一下就没必要发消息了。然后每个线程执行完后，flag 减一。，如果任务比线程多，正在执行的任务同时结束，还没来得及从队列取下一个任务，这时读锁还是全部解锁了，会误判全部任务结束。]]></description><category></category></item><item><title><![CDATA[有时候表数据多点查询速度反而快一点]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/139660067</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/139660067</guid><author>yang11qiang</author><pubDate>Fri, 14 Jun 2024 14:05:09 +0800</pubDate><description><![CDATA[所以我遇到的问题就是：虽然测试环境总数据多一点，按 test_a 排序的话。而正式环境，test_a  比  test_c  数据多很多，然后驱动表变成了 test_c。平时业务开发都会有排序，然后我就测试了排序对性能的影响（线上的那个老sql 是从20多秒，优化到了1秒内，我自己造的数据比较少，演示下意思就行了）也就是 test_c 成了驱动表，当排序字段在驱动表上时，才能正常使用索引排序。还有一个优化，如果id是递增的，很多时候排序都是按时间排序，这个时候直接改成按id排序，这样可以少建一个索引。]]></description><category></category></item><item><title><![CDATA[Mybatis-plus 分页查询的“坑”（不，是我不会用）]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/139076121</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/139076121</guid><author>yang11qiang</author><pubDate>Mon, 20 May 2024 23:19:41 +0800</pubDate><description><![CDATA[像百度，谷歌一样不需要展示具体页数和总条数，然而，上面我说的这些，没有打动产品经理，也没时间所有界面挨个修改，那目前就只能继续处理数量查询。经常做列表界面性能优化的小伙伴都遇到过这样的情况，索引什么的都命中，但是性能就是不好，其中一种情况就是因为 列表为分页查询，列表查询本身挺快的，但是拿到分页的count语句在数据库中执行慢的一批。因为，sql的select用了这样的函数，然后再去分页查询，这种本来就是不正确的使用方式，兼容了最好，报错提示开发者也行。不处理，也能接受吧，程序员自己使用错误在先。]]></description><category></category></item><item><title><![CDATA[java代码中一眼不容易发现的bug]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/139022576</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/139022576</guid><author>yang11qiang</author><pubDate>Sat, 18 May 2024 16:57:25 +0800</pubDate><description><![CDATA[CompletionService内部有一个阻塞队列，消费者是completionService.take()，就是去阻塞队列中获取 Future， 而生产者则是 completionService.submit，向队列放入Future，当生产者发放入的数量少于take()获取的数据量时，take()就会等待，直到有新的任务进入。然后呢，万千代码中相中了一个老熟人， CompletionService，这个工具类我自己还没用过，，，，但是长得和 CompletableFuture 有几分神似。]]></description><category></category></item><item><title><![CDATA[发现fastjson 2.0.32 版本的一个bug---数据转换错误]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/138632695</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/138632695</guid><author>yang11qiang</author><pubDate>Thu, 09 May 2024 23:47:00 +0800</pubDate><description><![CDATA[最近参与一个新的项目，测试同事发现一个数据不对，数据库的数据明明是，但是界面显示的却是，这个差距太大了吧。。。一路跟踪代码没有发现任何问题，最后debug发现，jsonObject.toJavaObject(XX.class)  这行代码之后数据就不对了，不会吧，又是fastjson的bug？之前已经遇到一次，数据量太大，fastjson报空指针的问题（版本升级解决），现在又遇到，，，，老司机第一反应就是，小数嘛，是不是精度问题，但是和。]]></description><category></category></item><item><title><![CDATA[java 异步表格导出]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/137143154</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/137143154</guid><author>yang11qiang</author><pubDate>Sun, 07 Apr 2024 16:57:54 +0800</pubDate><description><![CDATA[前端传入查询数据的链接和参数（导出列表数据的情况下，url和参数一般和界面的列表查询接口相同，这样可以减少一个专门的导出接口，在返回对象中添加对应的Excel注解用于生成表头和数据转换），构建请求信息去调用其他服务的查询接口，一定要带上用户信息，因为大部分系统都有数据权限，防止用户看到无权查看的内容。具体不记得了，，，，），我们项目种用的最多的就是第一种方式，带来的问题就是，数据量过大，内存飙升也发生过几次oom，用户体验方面，导出任务比较慢的情况，用户不能离开当前界面需要保持连接，还很可能超时。]]></description><category></category></item><item><title><![CDATA[消费者一次性取出全部数据的阻塞队列（java自定义）]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/135064660</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/135064660</guid><author>yang11qiang</author><pubDate>Mon, 18 Dec 2023 17:01:26 +0800</pubDate><description><![CDATA[这里就典型的生产消费问题， 生产一条，丢到线程池消费一条，然而当时的生产者性能远的高于消费者性能，于是决定做这样一个队列，生产者一条一条的产生数据后进入队列，消费者等待队列装满或者1秒以后还没装满就去消费。大概实现：“读” “写”相互等待，“写”满时或者达到超时时间唤醒 ”读“，“读”完立即唤醒 “写”原因： 当时要做一个优化， 大量的数据拉取后，需要同步到 ES，之前是多个线程一条条的插入，这样改造可以一次批量插入几十条数据到 ES，实际性能提升了很多（具体提升多少忘了）]]></description><category></category></item><item><title><![CDATA[mq消费比数据库事务快导致查询不到数据的解决办法思考]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/126308733</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/126308733</guid><author>yang11qiang</author><pubDate>Fri, 09 Dec 2022 17:50:06 +0800</pubDate><description><![CDATA[mq消费比数据库事务快的问题思考]]></description><category></category></item><item><title><![CDATA[feign 自动生成 FallbackFactory]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/126129990</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/126129990</guid><author>yang11qiang</author><pubDate>Tue, 02 Aug 2022 20:44:01 +0800</pubDate><description><![CDATA[feign 自动生成 FallbackFactory ]]></description><category></category></item><item><title><![CDATA[解决@Async导致ThreadLocal值丢失问题]]></title><link>https://blog.youkuaiyun.com/yang11qiang/article/details/125490779</link><guid>https://blog.youkuaiyun.com/yang11qiang/article/details/125490779</guid><author>yang11qiang</author><pubDate>Mon, 27 Jun 2022 20:07:21 +0800</pubDate><description><![CDATA[通过重写线程池，处理子线程threadLocal丢失的问题，并且拒绝策略是CallerRunsPolicy时，需要特别注意]]></description><category></category></item></channel></rss>