<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[没有进步就是退步]]></title><description><![CDATA[个人博客：https://callmejiagu.github.io/]]></description><link>https://blog.youkuaiyun.com/MakeContral</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; MakeContral]]></copyright><item><title><![CDATA[阿尔萨斯原理解析]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/96506573</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/96506573</guid><author>MakeContral</author><pubDate>Fri, 19 Jul 2019 22:18:30 +0800</pubDate><description><![CDATA[i_arthas 是模仿阿里开源的阿尔萨斯写的小工具。整体技术上采用 Java agent 对字节码的加载进 行拦截干涉，利用 ASM/ASM Byte Viewer 实现目标类字节码的加强，通过 Java attach 实现不同 虚拟机进程间的通信，做到了虚拟机层面上的 AOP。

整体实现了简易版的 redefine（热替换）、 watch（方法监控）、trace（方法链路追踪）、timeTunnel（流量采集与回放）等功能。]]></description><category></category></item><item><title><![CDATA[IO多路复用底层原理分析]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/89195923</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/89195923</guid><author>MakeContral</author><pubDate>Wed, 10 Apr 2019 21:43:44 +0800</pubDate><description><![CDATA[前言
最近一直忙着找实习以及小论文的实验，导致最近半个月都没有汲取到新的知识，也就这两天空闲的时候才能继续看看Netty。其实网上关于Netty的文章很多，但是能够从底层原理去解释的却不多，我们都知道Netty底层是通过IO多路复用来实现的，那么你们有没有考虑过在底层上IO多路复用又是是如何实现的？
这篇就从底层的select函数以及文件驱动poll函数来分享一下我的认识，若如有误的地方，大家可以...]]></description><category></category></item><item><title><![CDATA[如何定位生产环境中的问题(Java)]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/88561551</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/88561551</guid><author>MakeContral</author><pubDate>Thu, 14 Mar 2019 21:14:36 +0800</pubDate><description><![CDATA[前言
相信大家在平时工作中，或多或少遇到过些棘手的问题，如CPU负载过高、内存溢出、频繁Full GC等。对刚接触工作的同学来说的确是不知道从哪入手，所以这里我简单介绍一下上面三种问题该如何去定位以及解决，当然解决的方式是不一的，可以根据具体环境的问题灵活使用。

TOP 命令解析
Linux中top命令是排查问题最有效的利器，但是很多人对top认识不深刻，而且网上很多博客有些错误的阐述，所以这里...]]></description><category></category></item><item><title><![CDATA[词向量相似性（Word Similarity）、类比任务（Word Analogy）实验数据]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/86530380</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/86530380</guid><author>MakeContral</author><pubDate>Thu, 17 Jan 2019 20:00:01 +0800</pubDate><description><![CDATA[词向量验证的方法通常有: 词的相似性任务（Word Similarity） 以及 词的类比任务 (Word Analogy)。
词的相似性任务-Word Similarity

常用的英文数据集：WordSim-353 、MEN、SCWS
常用的中文数据集：wordsim-240、wordsim-297

词的类比任务-Word Analogy

常用的中文数据集：Chen 2015年构造的评测文...]]></description><category></category></item><item><title><![CDATA[多线程并发 之 synchronized 锁的优化]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85926242</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85926242</guid><author>MakeContral</author><pubDate>Sun, 06 Jan 2019 14:05:28 +0800</pubDate><description><![CDATA[为了提高阅读的体验，可以点击这里
前言
早期版本的synchronized在性能上比较差，好在Jdk1.6之后对其进行种种优化，那么这篇我们就来学习一下synchronized锁都有哪些优化操作！因为网上关于这块的解析比较多了，所以基础如自旋、Mark Word就不再复述了，主要讲我对锁优化的认识！

重量锁
我觉得要想了解 synchronized 的优化，就必须要先认识到早期 synchron...]]></description><category></category></item><item><title><![CDATA[FileChannle 和 MMAP 高性能分析]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85380197</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85380197</guid><author>MakeContral</author><pubDate>Sun, 30 Dec 2018 12:39:28 +0800</pubDate><description><![CDATA[前言
上一篇的博客中，我从底层上分析了BufferInputStream为什么效率会比FileInputStream来得高，这两种方式都是传统的IO，在JDK1.4 中NIO又多了两种新的IO方式：FileChannle 和 MMAP。这里着重来解释FileChannle的高性能的场景。

FileChannle
FileChannel 存在于 java.nio 包中，属于 NIO 的一种，但是注...]]></description><category></category></item><item><title><![CDATA[BufferedInputStream 底层原理解析]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85318673</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85318673</guid><author>MakeContral</author><pubDate>Fri, 28 Dec 2018 10:57:08 +0800</pubDate><description><![CDATA[前言
RMQ中为了实现高性能在IO上做了很多优化，在阿里中间件性能挑战赛也可以看到很多大神们在IO上花了很多功夫去分析优化，这篇主要来解析一下BufferedInputStream的实现原理，看看它在IO上做了哪些优化。

误区
看到很多文章是这么描述BufferedInputStream性能高的原因：BufferedInputStream 将数据先保存在了缓存区，从而减少磁盘IO操作次数，提高I...]]></description><category></category></item><item><title><![CDATA[内存映射 mmap的理解（转载+整理）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85170752</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85170752</guid><author>MakeContral</author><pubDate>Fri, 21 Dec 2018 19:47:10 +0800</pubDate><description><![CDATA[前言
上一篇解释了RMQ为了提高大文件的读写效率，使用了内存映射的方法，将磁盘上的文件与进程中的进程虚拟空间进行了映射，减少一次内核空间到用户空间的一次复制。看到这里我就有了疑惑，既然内存映射有这么好的特性，为什么还需要传统的IO呢？看下文的分析。

进程中的虚拟内存
mmap是将文件与进程虚拟空间进行了映射，所以你需要先明白进程虚拟空间是什么概念。下图的左边就是一个进程地址空间可视图。

你可以...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 消息存储（预备知识二）（转载+整理）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85156857</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85156857</guid><author>MakeContral</author><pubDate>Fri, 21 Dec 2018 09:31:04 +0800</pubDate><description><![CDATA[前言
在RMQ中为了提高commitlog文件的读写效率，而采用了一个叫做内存映射的技术。按照我的理解，内存映射在处理大文件上有非常大的性能提升，所以这篇来记录一下我对内存映射的理解。

用户态和内核态
我们都知道操作系统分为用户态和内核态，内核态表示当前为内核程序执行时的状态，用户态是用户程序代码运行的状态。用户态是不能直接和物理设备打交道的，如果想把硬盘的一块区域读到用户态，则需要两次拷贝(硬...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 消息存储（预备知识一）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85094005</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85094005</guid><author>MakeContral</author><pubDate>Wed, 19 Dec 2018 12:45:14 +0800</pubDate><description><![CDATA[前言
看到RocketMQ的性能问题的时候，通常能看到page cache、顺序IO写、预读等，要想设计出一个高性能的中间件，这部分的知识是绝对要掌握的。

顺序IO读写为什么速度更快
当需要从硬盘上读取一个文件时，首先会要求磁头定位到这个文件的起始扇区。这个定位过程包括两个步骤： 磁头定位到对应的磁道； 主轴马达带动盘片转动到正确的位置。
这个过程所花费的时间被称为寻址时间。也就是说寻址时间实际...]]></description><category></category></item><item><title><![CDATA[读源码感]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85093984</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85093984</guid><author>MakeContral</author><pubDate>Wed, 19 Dec 2018 12:44:28 +0800</pubDate><description><![CDATA[前言
最近的时间差不多都围绕着RocketMQ的学习上，一开始从了解RocketMQ的场景到RocketMQ的一个使用，然后到源码的阅读。前面两个过程无需多说，到了读源码的阶段，我时常问自己，读这份源码的意义在于哪？

感想
我从namesrv的启动类入手开始阅读，作为切入点我觉得没错，但是时常因为某个细枝末节的事情从而打断对整块功能块的认识。这点我觉得是在读源码的一个误区吧，首先你想要掌握所有的...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 BrokerStartUp（七）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85001137</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85001137</guid><author>MakeContral</author><pubDate>Fri, 14 Dec 2018 12:02:48 +0800</pubDate><description><![CDATA[前言
broker是消息接收处理，消息落地的核心模块。这个模块用于接收producer发送的消息以及consumer消费的消息。 本章从broker的启动类入手分析一下broker启动的过程。
分析broker是为了能够搞明白master和slave之间的关系，以及消息落地的具体过程。

createBrokerController
broker启动会获取外部传入的初始化参数， 也会从配置文件中加...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 NettyRemotingServer（六）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/85001108</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/85001108</guid><author>MakeContral</author><pubDate>Fri, 14 Dec 2018 12:01:36 +0800</pubDate><description><![CDATA[前言
已经写了几篇关于RocketMQ源码的分析，可能对其逻辑处理会多一点认识，但还没深入到RocketMQ精髓中。比如MQ中的通信是如何实现的、如何实现高性能，高可用、最终一致性、MQ 消息存储。这些才是我们阅读源码的一个目标。所以这篇通过分析源码的来了解一下RocketMQ通信机制。
本文很大部分摘录了 匠心独运的博客。

NettyRemotingServer
RocketMQ中RPC通信的...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 BrokerHousekeepingService（五）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/84982117</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/84982117</guid><author>MakeContral</author><pubDate>Thu, 13 Dec 2018 09:13:19 +0800</pubDate><description><![CDATA[前言
RocketMQ在早期版本使用的是Zookeeper，考虑到Zookeeper不够轻量，后面用namesrv来代替。熟悉Zookeeper的知道它使用心跳检测来判断服务是否正常，那么namesrv肯定也少不了这块功能，那么它是怎么判断一个Broker节点是否Live呢？如果一个Broker断开了namesrv是如何处理的呢？
在前面篇章提到NamesrvController的构造函数中有一个...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 RouteInfoManager（四）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/84964843</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/84964843</guid><author>MakeContral</author><pubDate>Wed, 12 Dec 2018 09:40:05 +0800</pubDate><description><![CDATA[前言
在上一章分析了NamesrvController的构造函数时，会生成一个RouteInfoManager对象，该对象存放着整个消息集群的相关消息，所以这里单独拿出来分析。其实试想一下namesrv的功能不就是一个提供了通信功能的一个队列嘛，而RouteInfoManager保留了所有信息的路由。所以要想弄明白RocketMQ，RouteInfoManager必须要攻下。

RouteInfo...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 NamesrvController（三）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/84950009</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/84950009</guid><author>MakeContral</author><pubDate>Tue, 11 Dec 2018 09:34:38 +0800</pubDate><description><![CDATA[前言
上一篇在讲到createNamesrvController方法的时候，根据NamesrvConfig和NettyServerConfig对象生成了一个NamesrvController对象，当时并没有deep到该类中，所以这篇来记录一下NamesrvController构造函数的分析。

NamesrvController类
下面是NamesrvController的构造类，这里重点关注的是...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 NamesrvStartup（二）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/84949957</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/84949957</guid><author>MakeContral</author><pubDate>Tue, 11 Dec 2018 09:30:31 +0800</pubDate><description><![CDATA[前言
上一篇讲到使用命令行启动namesrv时，最终会以NamesrvStartup作为为启动类，所以这篇主要来记录一下NamesrvStartup的源码分析。分析的RocketMQ的版本是4.3.1。

NamesrvStartup
首先我觉得在看源码的时候，需要把握住一个类的大概流程，而不是看到一个功能块就deep进去。首先要明白namesrv是用来做什么的，简单的来考虑就是一个提供了通信功能...]]></description><category></category></item><item><title><![CDATA[RocketMQ 源码分析 nameser启动（一）]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/84898603</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/84898603</guid><author>MakeContral</author><pubDate>Sat, 08 Dec 2018 20:31:09 +0800</pubDate><description><![CDATA[前言
在RocketMQ中，NameServer的目的是为了解耦Broker和Producer、Consumer。官方文档对NameServer有一个概括：NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。而且在启动MQ的时候，第一个启动必须是NameServer。所以这篇主要来记录一下NameServer启动的源码分析。
脚本启动
无论在Windows或者是Linux...]]></description><category></category></item><item><title><![CDATA[基于MySQL网络通信协议  编写自己的JDBC]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/83656877</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/83656877</guid><author>MakeContral</author><pubDate>Fri, 02 Nov 2018 16:00:01 +0800</pubDate><description><![CDATA[基于MySQL网络协议实现自己的数据库驱动。主要是利用Wireshark解析MySQL的packet，使用Socket实现通信。具体实现思路可以点击下方的个人博客查看 。代码上传至GitHub。
在实现功能，借鉴了 sea-boat的packet实现，在其基础上进行功能块的编写，如查询功能可以看下面列子
package com.jiagu.mysql.CURD;

/**
 * Created b...]]></description><category></category></item><item><title><![CDATA[python乱码解决]]></title><link>https://blog.youkuaiyun.com/MakeContral/article/details/83059301</link><guid>https://blog.youkuaiyun.com/MakeContral/article/details/83059301</guid><author>MakeContral</author><pubDate>Mon, 15 Oct 2018 15:16:09 +0800</pubDate><description><![CDATA[利用chardet.detect 解析字符串的格式先，然后将其转码Unicode，然后再转为utf-8
# coding=utf-8
import sys
import chardet
import codecs
import os
reload(sys)
sys.setdefaultencoding('utf-8')

fileT = codecs.open(r'C:\Users\GEKL\De...]]></description><category></category></item></channel></rss>