UTF8 中文占多少字节问题
看了网上一堆人扯淡的人云亦云,有的说是3字节,有的说是2字节-4字节,有的说是4字节。 本来昨晚帮同事解决中文乱码问题,对这个提起了兴趣,查了下wiki百科里面unicode编码表。 只要在CJK的部分就可能有汉字,为此专门随机挑选了几个CJK下的表看了下,大多数都是3字节的,但是有存在4字节的情况。 不信邪的小伙子们可以拿下面这个表去测试下,哈 ![](https://cdn.yuxianghe.net/image/blog/25-1.jpg) 也就是说按照目前的情况来看 > 有CJK的可能就有汉字,所以不局限于0X4E00到0x9FA5,也不要绝对的认为0X9FA5就是尽头,0X4E00就是起点。

2018-12-27 02:25

类型:工作 标签:utf8,中文

JBoss 中文乱码
新来的同事在搞开放平台,一个乱码问题整了很久,主要是对JBoss的配置不是很熟悉,我以前遇到过这种情况,就帮着解决了下。 第三方应用调用开放平台的接口,GET请求,参数直接在URL上,其中参数存在中文,默认的设置会乱码。 JBoss的配置和tomcat类似。 ``` <Connector port="8080" address="${jboss.bind.address}" maxThreads="1000" maxHttpHeaderSize="8192" emptySessionPath="true" protocol="HTTP/1.1" enableLookups="false" redirectPort="8443" acceptCount="500" connectionTimeout="20000" disableUploadTimeout="true" /> ``` 在尾部添加 ``` URIEncoding="UTF-8" ``` 变成了: ``` <Connector port="8080" a...

2018-12-26 13:34

类型:工作 标签:jboss,java

JVM 参数调优
看zabbix报错日志的时候,发现集群环境的很多服务的堆内存有异常 具体表现如下: 某个时间某机器出现大量的RPC调用超时,持续大致一分钟左右,偶尔还会出现机器的拉起脚本判定服务失联,kill掉之后重新启动。 这些现象都伴随着堆内存占用非常高,且查看gc日志发现此时进行了fullGC,时间长达56S的fullGC! 在没进行fullGC的前二十四个小时内,堆内存占用是稳步缓缓上升的,没有明显的下降趋势 初次怀疑内存泄露或者是垃圾回收导致的 ``` jcmd pid GC.class_histgram ``` 发现没有什么异常对象 ``` 1: 127986 16991200 [C 2: 13598 9982736 [B 3: 124786 2994864 java.lang.String 4: 34740 2768024 [Ljava.lang.Object; 5: 83259 2664288 java.ut...

2018-12-21 13:13

类型:工作 标签:jvm,gc

Xstream 对象使用不当导致 CPU 居高不下
公司内某开放平台集群服务出现了些许用户投诉,起初我们不以为意,直到看到了一个很有意思的用户反馈。 开放平台会给根据用户的行为不同推送消息,本来按照正常逻辑,A消息推送永远都会在B消息之前的。 但是用户反馈先收到的B消息,大约十分钟之后收到的A消息,这就有问题了。 我们的消息都是走的kafka,看了下日志的确发生了B消息先推送,A消息后推送的情况,这就不科学了。 首先想到的就是kafka消息积压了,因为A,B两种消息不在一个topic 看了下集群里的机器都会陆续出现CPU暴涨的情况,而且居高不下,一个个接着出现这种情况, ![](https://oscimg.oschina.net/oscnet/2abbf53dd0022d92815b90b092b93bcc0d2.jpg) 马上看zabbix,找到CPU暴涨的时间段的机器查看它的jstack日志 发现了那台机器有166个RUNNABEL的一样的堆栈信息,别的时间段CPU暴涨的机器的jstack日志也有一模一样的这样的日志,平均都是160+左右。 ``` "pool-5-thread-95881" #174383 prio=5 os_pr...

2018-12-11 12:40

类型:工作 标签:xstream,java

kafka 重复消费问题的排查过程
在压力测试过程中,请求的峰值一直持续的时候就容易出现了大量的XX字段插入失败,唯一键冲突。 检查日志能发现出现大量的提交到kafka失败 ``` Commit cannot be completed due to group rebalance ``` 很多次提交到kafka都是rebalance,为什么发生了rebalance 我们的应用是开三个线程消费kafka消息,拿到消息后就会进行提交,理论上是不应该出现这种情况的。 > kafka 版本在1.0之前是通过客户端poll消息的间隔来判断客户端是否挂掉,1.0 版本改为用单独的线程维持心跳判断是否挂掉。 这个重复消费的集群使用kafka客户端是用的0.9的版本,这就意味着是通过poll消息的间隔来判断是否挂掉。 当poll下消息处理时间超过30秒的时候就会导致发生rebalance,提交失败,紧接着别的机器又消费到了这批消息。 其次,我们把kafka的session超时时间设置由原来的30秒改为了90秒,也就是说间隔时间超过90秒才会rebalance。 改变之后问题不再发生重复消息的情况, 但是日志刷新有卡顿的情况,也就是说有什么逻...

2018-12-05 12:12

类型:工作 标签:kafka,rebalance,java

我与我周旋久 独孤影 开源实验室