发表更新踩坑记录6 分钟读完 (大约825个字)

MySQL多字段排序的问题

最近在一次开发过程中发现了一个问题，我们都知道MySQL在Order By的时候可以指定多列，会按照指定的顺序依次排序。

例如指定A,B,C列，MySQL会先按A排序，如何A值相同的再按B排序，B值相同的再按C排序。

然后其中还是有不少门道的，例如我就碰到了如下问题，我有一个表test，表结构如下：

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `test` (

`A` varchar(128) NOT NULL COMMENT 'A',

`B` varchar(64) NOT NULL COMMENT 'B',

`C` varchar(64) NOT NULL COMMENT 'C'

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='TEST'

其中有如下数据：

A B C
C料 12321 123
c料 测试 SPHC
c料 测试 SPHC
C料 测试 测试
C料 测试 测试

接着执行如下查询

1
2
3

select * from test order by A,B,C

按照我们上面的说法最后出来的结果应该是：

A B C
C料 12321 123
C料 测试 测试
C料 测试 测试
c料 测试 SPHC
c料 测试 SPHC

然而实际出来而结果是：

A B C
C料 12321 123
c料 测试 SPHC
c料 测试 SPHC
C料 测试 测试
C料 测试 测试

可以看到的是A列明显乱序了（注意C大小写），不是说好A相同的排序在一起呢，怎么看起了不对了。

既然是按照列的顺序一个一个排序的，那我们就一个一个排除，看看到底是在哪一列排序出了问题。

执行如下查询：

1
2
3

select * from test order by A,B

得到如下结果：

A B C
C料 12321 123
C料 测试 测试
C料 测试 测试
c料 测试 SPHC
c料 测试 SPHC

也就是说在C列加入排序之前，A还是看着有序的，那到底是怎么回事呢？注意回到最开始我们说的MySQL的排序规则，A相同再按B排，B相同按C排。

所以C在加入排序之前，MySQL认为A，B排序后有相同的结果，也就是c料,测试=C料,测试了，所以C加入排序之后可以在前者相同的排序结果中在按C排序。

于是就产生了看起来错误的顺序，这是因为创建表的时候，没有对字段A，B，C指定collation（MYSQL排序依据），默认会使用对应字符集的Collation，

我这里字符集是utf8mb4，对应的默认collation通常是utf8mb4_general_ci，这个collation是大小写不敏感的。

解决办法有两种：

1.更改字段的collation，

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `test` (

`A` varchar(128) NOT NULL COMMENT 'A' COLLATE utf8mb4_bin,

`B` varchar(64) NOT NULL COMMENT 'B' COLLATE utf8mb4_bin,

`C` varchar(64) NOT NULL COMMENT 'C' COLLATE utf8mb4_bin

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='TEST'

使用utf8mb4_bin，这个是大小写敏感的。

2.在排序的时候指定BINARY关键字

1
2
3

select * from test order by binary A,binary B, binary C

因为它会强制MySQL将字段作为二进制字符串对待。

由于这是一个历史存在的表，避免产生其它意向不到的结果，我使用了方法二。至此问题解决。

发表更新踩坑记录10 分钟读完 (大约1435个字)

记一次线上Spring和Dubbo死锁排查

问题

前不久线上发现有系统间数据没有同步，排查一通下来发现应该是 MQ 消息没有被消费，通过 MQ Console 发现，未被消费的消息全都集中的一台机器上（消息投放的queue 以及 rebalance 关系），此时我有两个怀疑，一是消费者线程挂了，二是此服务分配到的消息队列出了什么莫名的问题。由于正值业务高峰，领导第一时间重启了服务，重启后一切恢复正常。排查由于一些其它事项，也到此中断。

然而没过多久，我听到其它需求项目组在测试环境出现了相同的问题，也是消息不消费了，导致业务异常。我立马找到对应服务 dump 了线程。

我将 dump 文件通过 visualVM 打开，然后得到了很明显的提示：Found one Java-level deadlock:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
"ConsumeMessageThread_1":
  waiting to lock monitor 0x00007f1350390f18 (object 0x000000008024ebc0, a java.util.concurrent.ConcurrentHashMap),
  which is held by "main"
"main":
  waiting to lock monitor 0x00007f1330071f18 (object 0x0000000080fb6318, a org.apache.dubbo.config.deploy.DefaultModuleDeployer),
  which is held by "Thread-26"
"Thread-26":
  waiting to lock monitor 0x00007f1350390f18 (object 0x000000008024ebc0, a java.util.concurrent.ConcurrentHashMap),
  which is held by "main"

Java stack information for the threads listed above:
===================================================
"ConsumeMessageThread_1":
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:187)
        - waiting to lock <0x000000008024ebc0> (a java.util.concurrent.ConcurrentHashMap)
        at org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch(AbstractBeanFactory.java:486)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.doGetBeanNamesForType(DefaultListableBeanFactory.java:432)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:403)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:515)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:508)
        at org.springframework.context.support.AbstractApplicationContext.getBeansOfType(AbstractApplicationContext.java:1186)
        ...
        at org.apache.rocketmq.client.impl.consumer.ConsumeMessageConcurrentlyService$ConsumeRequest.run(ConsumeMessageConcurrentlyService.java:411)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
"main":
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.startSync(DefaultModuleDeployer.java)
        - waiting to lock <0x0000000080fb6318> (a org.apache.dubbo.config.deploy.DefaultModuleDeployer)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.start(DefaultModuleDeployer.java:139)
        at org.apache.dubbo.config.ReferenceConfig.get(ReferenceConfig.java:228)
        ...
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
        at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1173)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1067)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:513)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
        - locked <0x000000008024ebc0> (a java.util.concurrent.ConcurrentHashMap)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761)
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
        - locked <0x00000000804b98b0> (a java.lang.Object)
        at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122)
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:693)
        at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:360)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:303)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1118)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1107)
        at com.internet.saasbillmanager.ApplicationMain.main(ApplicationMain.java:46)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:51)
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:52)
"Thread-26":
        at org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:185)
        - waiting to lock <0x000000008024ebc0> (a java.util.concurrent.ConcurrentHashMap)
        at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:128)
        at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:393)
        at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:347)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener.publishEvent(DubboDeployApplicationListener.java:91)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener.access$000(DubboDeployApplicationListener.java:47)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener$1.onStarted(DubboDeployApplicationListener.java:70)
        at org.apache.dubbo.config.spring.context.DubboDeployApplicationListener$1.onStarted(DubboDeployApplicationListener.java:62)
        at org.apache.dubbo.common.deploy.AbstractDeployer.setStarted(AbstractDeployer.java:121)
        at org.apache.dubbo.config.deploy.DefaultApplicationDeployer.onStarted(DefaultApplicationDeployer.java:989)
        at org.apache.dubbo.config.deploy.DefaultApplicationDeployer.checkState(DefaultApplicationDeployer.java:868)
        - locked <0x0000000080fa6c10> (a java.lang.Object)
        at org.apache.dubbo.config.deploy.DefaultApplicationDeployer.notifyModuleChanged(DefaultApplicationDeployer.java:851)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.onModuleStarted(DefaultModuleDeployer.java:264)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.startSync(DefaultModuleDeployer.java:171)
        - locked <0x0000000080fb6318> (a org.apache.dubbo.config.deploy.DefaultModuleDeployer)
        at org.apache.dubbo.config.deploy.DefaultModuleDeployer.start(DefaultModuleDeployer.java:139)
        at org.apache.dubbo.config.ReferenceConfig.get(ReferenceConfig.java:228)
        at org.apache.dubbo.config.spring.ReferenceBean.getCallProxy(ReferenceBean.java:346)
        at org.apache.dubbo.config.spring.ReferenceBean.access$100(ReferenceBean.java:99)
        at org.apache.dubbo.config.spring.ReferenceBean$DubboReferenceLazyInitTargetSource.createObject(ReferenceBean.java:353)
        at org.springframework.aop.target.AbstractLazyCreationTargetSource.getTarget(AbstractLazyCreationTargetSource.java:86)
        - locked <0x0000000085b49868> (a org.apache.dubbo.config.spring.ReferenceBean$DubboReferenceLazyInitTargetSource)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:192)
       ...
        at com.xxl.job.core.thread.JobThread.run(JobThread.java:152)

Found 1 deadlock.

这里有 3 个线程：

  • “ConsumeMessageThread_1” MQ 消费者线程

  • “main”: 主线程

  • “Thread-26”: XXL-JOB 执行线程

其实主要是这两个线程引发的问题：

  • “main”: 主线程

  • “Thread-26”: XXL-JOB 执行线程

MQ 消费者线程是正好撞在枪口上了。

涉及两个锁：

  • DefaultModuleDeployer：object monitor lock

  • DefaultSingletonBeanRegistry.singletonObjects：object monitor lock

暂且将第一个称为 Dubbo 锁，第二个称为 Spring 锁。

“main”: 主线程做的事情是初始化一个基础服务（Dubbo Consumer）注册到 Spring 和 Dubbo 中， 而其先获取到了 Spring 锁，再去获取 Dubbo 锁。

“Thread-26”：job 线程是由 xxljob 触发后执行一个任务，需要调用一个远程的 Dubbo 服务，于是 先获取了 Dubbo 锁，再去获取 Spring 锁。

于是两个线程就互相锁死了，而 MQ 消费者线程，也要去Bean Container 中获取 Bean，也需要获取 Spring 锁，也就卡死了。

解决方案

这个问题由于是在启动过程中发生，所以我设想了两个解决方案（没有好的契机去解决这个问题，只能等到有相关需求了），其实思路是同一个，那就是将出问题的 Bean 给延迟加载：

  • 将“基础服务”Bean 给@Lazy。
  • 将“XxlJobSpringExecutor”在spring启动完成之后再注册进容器，避免启动过程中收到任务的执行命令。
发表更新踩坑记录5 分钟读完 (大约822个字)

老版本Dubbo的一个bug

线上有用户反应P 服务页面时不时就报个错，后来发现都涉及I服务的一个接口方法，这里暂且就叫F 接口。只是时不时报错，那说明可能是某些参数会导致异常，于是我开始查看日志，看看是不是有什么特殊参数导致隐藏 bug 被发现。
结果是报错和不报错的请求参数都一样，那是不是多台机器上运行的代码不一致呢？于是我看了F 接口的代码，发现最近没有迭代记录，而且所有机器上部署的代码均一致。
那有没有可能是环境问题？于是我上 Dubbo 控制台查看，发现 provider 和 consumer 都正常：
DubboAdmin
这个时候我开始有点懵逼了😅。

我又想到，如果是一直存在问题，那么不可能到今天才有用户反馈，所以还是跟近期的什么操作有关。于是我开始排查最早是什么时间出现的问题，发现是 10 月 10 日的 18:00:03，又发现F 接口所在的I服务在10 月 10 日的 17:57:28有过发布记录。
release

这下就有点奇怪了，就算I服务所有机器同时发布，可能也就是报一会 no providers错误啊，更不用说是滚动发布的，加上 dubbo 的 failover不会一直报错的啊。

就在这时我看到了一个关键的错误信息：（之前只看到了 NPE 没具体位置）：
Error

问题直指DubboInvoker:109。

我们 dubbo的版本是(2.6.6)，我拉下dubbo 代码发现这块的代码是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Override
public boolean isAvailable() {
    if (!super.isAvailable())
        return false;
    for (ExchangeClient client : clients) {
        //这一行是 109，就是这一行报错
        if (client.isConnected() && !client.hasAttribute(Constants.CHANNEL_ATTRIBUTE_READONLY_KEY)) {
            //cannot write == not Available ?
            return true;
        }
    }
    return false;
}

109 行报 NPE 莫非 client 是 null？带上猜测我开始看 client 是怎么来的，最终找到com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol#getSharedClient:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private ExchangeClient getSharedClient(URL url) {
        String key = url.getAddress();
        ReferenceCountExchangeClient client = referenceClientMap.get(key);
        if (client != null) {
            if (!client.isClosed()) {
                client.incrementAndGetCount();
                return client;
            } else {
                //3
                referenceClientMap.remove(key);//4
            }
        }

        locks.putIfAbsent(key, new Object());
        synchronized (locks.get(key)) {//2
            if (referenceClientMap.containsKey(key)) {
                return referenceClientMap.get(key);//5
            }

            ExchangeClient exchangeClient = initClient(url);
            client = new ReferenceCountExchangeClient(exchangeClient, ghostClientMap);
            referenceClientMap.put(key, client);
            ghostClientMap.remove(key);
            locks.remove(key);
            //1
            return client;
        }
    }

又是一段平平无奇的代码😅，看到这里有用到锁，说明开发者考虑到这里可能会存在并发调用。我又看了下日志，10 月 10 日的 18:00:03前后确实出现了并发调用的现象，难道是这里的并发控制有 bug？于是我开始思考各种场景，还真被我发现一种可能出问题的情况，下面我画了个图演示一下：

flow

最后 序号 5 处返回了一个 null 的 client。

由于2.6.6 版本已经有点老，指不定这个问题已经有人提过，于是我到 github 一番搜索，结果找到了另外一个问题：https://github.com/apache/dubbo/issues/6444

这块dubbo 后面也迭代了好几次，已经搞不清楚了。

最后，重启大法好！

发表更新3 分钟读完 (大约475个字)

关于 java 中的可用内存问题

最近看了《why 技术》的一篇文章《这个队列的思路是真的好，现在它是我简历上的亮点了。》。本来没什么问题，觉得这么好的东西不拿来用一用太可惜了。于是我就搞到了项目中，但是却发现一个问题，文中提到的：

1
2
MemoryUsage heapMemoryUsage = MX_BEAN.getHeapMemoryUsage();
long availableMemory = heapMemoryUsage.getCommitted();

我发现availableMemory在一段时间内没什么变化。

我是这么测试的：

1
2
3
4
5
6
7
8
9
10
public static void main(String[] args) throws InterruptedException {
       List<byte[]> objects = new ArrayList<>();
       long _1MB = 1024 * 1024;
       while (true) {
           MemoryUsage heapMemoryUsage = MX_BEAN.getHeapMemoryUsage();
           System.out.println("committed:"+heapMemoryUsage.getCommitted()/_1MB);
           objects.add(new byte[1024 * 1024 * 50]);
           Thread.sleep(100L);
       }
   }

讲道理应该实时变化才对，后来我点进去了why哥留下的PR链接，发现这个PR在2022-06-06有一个提交：
1
备注信息为:”fix bug”，具体的修改为：
2
可以看到原来通过MemoryUsage获取可用内存变成了：

1
Runtime.getRuntime().freeMemory()

也就是说之前使用的getCommited()获取的并不是可用内存，于是我看了下MemoryUsage的源码(jdk8)，哈哈哈😂，发现图示的很清楚：
3
真正的可用空间是committed - used，于是我又做了下面的测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
public static void main(String[] args) throws InterruptedException {
       List<byte[]> objects = new ArrayList<>();
       long _1MB = 1024 * 1024;
       while (true) {
           MemoryUsage heapMemoryUsage = MX_BEAN.getHeapMemoryUsage();
           long freeMemory = Runtime.getRuntime().freeMemory();
           System.out.println("freeMemory："+freeMemory/_1MB);
           System.out.println("committed:"+heapMemoryUsage.getCommitted()/_1MB);
           System.out.println("committed - used:"+(heapMemoryUsage.getCommitted()-heapMemoryUsage.getUsed())/_1MB);
           objects.add(new byte[1024 * 1024 * 50]);
           Thread.sleep(100L);
       }
   }

4

可以看到确实如此。

20220615更新

why哥给我回复了，这个问题大佬也讨论过https://github.com/apache/dubbo/pull/10021#issuecomment-1147464751

其中一个大佬说的可用内存应该是：

1
MemoryUsage#getMax() - MemoryUsage#getUsed()

然后我在 github 上回复了一下大佬，大佬给我的答复是：
5

发表更新Java随记3 分钟读完 (大约477个字)

什么?Lombok有坑?

事情是这样的，前段时间有个线上bug需要我去排查：
1

首先看了CAT的调用链，并没有发现什么问题，所有的服务都是正常处理结束。

于是我要了一个traceId，去排查日志，也是没有发现什么问题。

我拉下了生产版本的代码，走查了一下逻辑，并没有发现什么大问题，所以这注定是一个细节问题。

由于这是一个可以复现的问题，所以让测试大佬在测试环境模拟了下有问题的数据，于是我开始Debug了。

一行一行代码的看，一个一个变量的watch，最终发现了问题。

2

首先是同事新增了如下代码：

3

然后数据的OwnerId都是null：

4

紧接着执行了这个removeAll:

5

可是这为什么会出问题呢？

原来是list中的对象，是同事新加的，继承了原有的对象：

6

并且使用了Lombok的Data注解。这个注解会生成equals方法：

7

removeAll是调用的equals判断对象是否相同，equals方法重写后，导致只要这两个对象的ownerId都为空就会认为相同。

可以看到一个@Data注解相当于加了6个注解：

8

怎么解决这个问题呢？既然问题出在equals，那么有没有什么办法让子类生成的equals中也能包含基类的属性呢？

是有的：

1
@EqualsAndHashCode(callSuper = true)

加上这个注解就可以了。

可以看到@Data注解做的事情太多了，会发生你意想不到的情况，实际是不太推荐无脑使用的，建议还是自己组合需要的注解。

发表更新工具分享6 分钟读完 (大约870个字)

Spotlight替代工具uTools及插件分享

Mac自带的Spotlight对于普通用户来说已经够用了，高阶一点的会使用alfred来增强，但是alfred交互方式比较单一，通常是列表方式，也不支持通过输入内容匹配wf，通常需要keyword唤醒。而且alfred是收费软件。

uTools

uTools 也是一款Spotlight增强应用，默认的唤醒快捷键是option+space，墙裂推荐改为double command。应用的主界面长这样：

uTools应用的逻辑有点像微信小程序，可以通过keyword呼出小程序，也可以通过剪切板内容自动识别出来。

阅读更多
发表更新Java随记8 分钟读完 (大约1170个字)

Dubbo调用超时那些事儿

其实之前很早就看过dubbo源码中关于超时这部分的处理逻辑，但是没有记录下来，最近在某脉上看到有人问了这个问题，想着再回顾一下。

开始

从dubbo的请求开始，看看dubbo（2.6.6）在超时这块是怎么处理的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel#request(java.lang.Object, int) 
 @Override
    public ResponseFuture request(Object request, int timeout) throws RemotingException {
        if (closed) {
            throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");
        }
        // create request.
        Request req = new Request();
        req.setVersion(Version.getProtocolVersion());
        req.setTwoWay(true);
        req.setData(request);
        DefaultFuture future = new DefaultFuture(channel, req, timeout);
        try {
            channel.send(req);
        } catch (RemotingException e) {
            future.cancel();
            throw e;
        }
        return future;
    }
阅读更多
发表更新Java随记4 分钟读完 (大约576个字)

Java双亲委派机制的妙用

最近在项目中看到一段通过easyexcel导出动态表头的实现，开始我以为是easyexcel官方的实现，其中有这样一段代码：

1
2
3
4
5
6
7
8
//将动态表头上传至ThreadLocal
saveToThreadLocal(clz, result);

private <T> void saveToThreadLocal(Class<T> clz, List<String> result) {
        Map<Class,List<String>> paramMap = new ConcurrentHashMap<>();
        paramMap.put(clz, result);
        ThreadLocalUtil.FIELD_CACHE_MAP.set(paramMap);
}
阅读更多
发表更新踩坑记录11 分钟读完 (大约1694个字)

同事问了我一个关于RocketMQ的问题

同事突然问我：RocketMQ的一个消息，多次消费重试，消息的msgId会不会变？哪怕已经进了DLQ。

刚开始出于经验，我说不会变。因为我之前每次排查问题的时候，用同一个msgId都能找到多次重试消费的日志。后来为了更加确定，我卷了一下源码，我看的是4.6.1，一是因为公司用的这个版本，二是我上次卷的就是这个版本。。。

消息重试

既然跟重试有关，那就从客户端消费失败的逻辑开始，看看能不能找到蛛丝马迹，下面是消费失败将消息发回broker的代码：

阅读更多
发表更新工具分享2 分钟读完 (大约352个字)

PDF转EPUB工具分享

首先说下，有经济条件的还是建议购买纸质书阅读啊！

前言

现在网上很多资料都是有在线版的，但是有时候到一些网络不好的地方就很尴尬了。不过同时大佬们也会提供PDF版本，但是个人觉得PDF的阅读体验实在太差了。

我一直觉得epub格式的阅读体验不错，适配各种显示设备。关于epub是什么，可以看看wiki上的介绍：

阅读更多
关注我

链接

分类

归档

最新文章

标签

ASM1
Activiti1
BUG2
Bug1
CAP1
CPU1
Chrome1
DeadLock1
Deadlock1
Docker3
Dubbo3
EPUB1
Golang8
IDEA1
IRIW1
Java27
Lombok1
Maven1
MessageId1
MongodDB2
MySQL5
Mybatis1
OCR1
PDF1
Paxos1
Python3
RPC1
RocketMQ2
Spotlight1
Spring2
UniqKey1
VSCode1
dubbo1
elasticsearch1
flume1
kafka2
launchctl1
linux1
uTools1
volatile1
一致性1
博客1
双亲委派1
可用内存1
图床1
定时任务1
并发1
开源1
效率1
死锁1
爬虫1
电子书1

follow.it

×