背景这几天确实太忙了，之前是日更，说上班后来个隔日更，还是坚持不了。完成Q1季度的考评后发现群里有人问了一个问题，非常的有意思。当时我也是非常的懵逼，然后想自己尝试的去解决一下。 问题是：0xee 0xb9 转short得到 -4423 为什么？对啊，为什么？我TM也想知道。 其实到这里，我先总结一下： 计算机为什么能计算你这么快，原因是它只会处理0与1，二级制； 其实到硬件上面表现的就是电流信号、脉冲信号； 计算机虽然支持减法，乘法，除法，实际上底层只会一种算法，那就是加法； 这也就是当时大学老师跟我们说的，别以为计算机很厉害，其实它很傻逼。每一步操作都需要设定好逻辑与程序。 恶补基础知识点我们还是梳理一下基础知识吧~ 1、byte：有符号（意思是有正和负），在网络传输中都是会用到byte的，它占1个字节，共8位，比如说11111111就可以用1个byte表示，转化为10进制：- （2的6次+2的5次+2的4次+2的3次+2的2次+2的1次+2的0次） = -127。其中前7位表示数字，最高位表示符号，0为正，1为负。范围是 （-2的7次 ~ 2的7次 - 1），那为什么前 ...

背景在SpringBoot环境中，我们有“使用不完的”注解。这也是SpringBoot替代了传统的Spring项目中的xml配置的原因。在使用这些annotation的时候，我们一定要了解这些注解背后的原理以及约定。 12345678910111213141516package org.springframework.boot.context.properties;import java.lang.annotation.Documented;import java.lang.annotation.ElementType;import java.lang.annotation.Retention;import java.lang.annotation.RetentionPolicy;import java.lang.annotation.Target;import org.springframework.core.annotation.AliasFor;@Target({ ElementType.TYPE, ElementType.METHOD })@Retentio ...

概述UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多，因为即使丢失少量的包，也不会对接受结果产生较大的影响。 传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。 最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。 1、添加seq/ack机制，确保数据发送到对端 2、添加发送和接收缓冲区，主要是用户超时重传。 3、添加超时重传机制。 详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。 目前有如下开源程序利用udp实现了可靠的数据传输。分别为 RUDP、RTP、UDT。 开源程序1、RUDP（Reliable User Datagram Protocol）RUDP 提供一组数据服务质量增强机制，如拥塞 ...

粘包拆包问题是处于网络比较底层的问题，在数据链路层、网络层以及传输层都有可能发生。我们日常的网络应用开发大都在传输层进行，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。 什么是粘包、拆包？假设客户端向服务端连续发送了两个数据包，用packet1和packet2来表示，那么服务端收到的数据可以分为三种，现列举如下： 第一种情况：接收端正常收到两个数据包，即没有发生拆包和粘包的现象，此种情况不在本文的讨论范围内。 第二种情况：接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。 第三种情况：这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。 为什么会发生TCP粘包、拆包？发生TCP粘包、拆包主要是由于下面一些原因： 应用程序写入的数据大于套接字缓冲区大 ...

在这之前我只记住了StringBuilder不是线程安全的，StringBuffer是线程安全的这个结论，至于StringBuilder为什么不安全从来没有去想过。 分析 在分析设个问题之前我们要知道StringBuilder和StringBuffer的内部实现跟String类一样，都是通过一个char数组存储字符串的，不同的是String类里面的char数组是final修饰的，是不可变的，而StringBuilder和StringBuffer的char数组是可变的。 首先通过一段代码去看一下多线程操作StringBuilder对象会出现什么问题。 1234567891011121314151617181920public class StringBuilderDemo { public static void main(String[] args) throws InterruptedException { StringBuilder stringBuilder = new StringBuilder(); for (int i ...

概述本方法（invokeBeanFactoryPostProcessors）会实例化和调用所有 BeanFactoryPostProcessor（包括其子类BeanDefinitionRegistryPostProcessor）。 BeanFactoryPostProcessor 接口是 Spring 初始化 BeanFactory 时对外暴露的扩展点，Spring IoC 容器允许 BeanFactoryPostProcessor 在容器实例化任何 bean 之前读取 bean 的定义，并可以修改它。 BeanDefinitionRegistryPostProcessor 继承自 BeanFactoryPostProcessor，比 BeanFactoryPostProcessor 具有更高的优先级，主要用来在常规的 BeanFactoryPostProcessor 检测开始之前注册其他 bean 定义。特别是，你可以通过 BeanDefinitionRegistryPostProcessor 来注册一些常规的 BeanFactoryPostProcessor，因为此时所有常规的 B ...

本文主要是分析Spring bean的循环依赖，以及Spring的解决方式。 通过这种解决方式，我们可以应用在我们实际开发项目中。 什么是循环依赖？怎么检测循环依赖Spring怎么解决循环依赖Spring对于循环依赖无法解决的场景Spring解决循环依赖的方式我们能够学到什么？ 什么是循环依赖？循环依赖其实就是循环引用，也就是两个或则两个以上的bean互相持有对方，最终形成闭环。比如A依赖于B，B依赖于C，C又依赖于A。如下图： 注意，这里不是函数的循环调用，是对象的相互依赖关系。循环调用其实就是一个死循环，除非有终结条件。 Spring中循环依赖场景有：（1）构造器的循环依赖（2）field属性的循环依赖。 怎么检测是否存在循环依赖检测循环依赖相对比较容易，Bean在创建的时候可以给该Bean打标，如果递归调用回来发现正在创建中的话，即说明了循环依赖了。 Spring怎么解决循环依赖Spring的循环依赖的理论依据其实是基于Java的引用传递，当我们获取到对象的引用时，对象的field或则属性是可以延后设置的(但是构造器必须是在获取引用之前)。 Spring的单例对象的初始 ...

跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。 跳跃表支持平均O（logN）、最坏O（N）复杂度的节点查找，还可以通过顺序性操作来批量处理节点。在大部分情况下，跳跃表的效率可以和平衡树相媲美，并且因为跳跃表的实现比平衡树要来得更为简单，所以有不少程序都使用跳跃表来代替平衡树。 Redis使用跳跃表作为有序集合键的底层实现之一，如果一个有序集合包含的元素数量比较多，又或者有序集合中元素的成员（member）是比较长的字符串时，Redis就会使用跳跃表来作为有序集合键的底层实现。 以下是个典型的跳跃表例子 从图中可以看到， 跳跃表主要由以下部分构成： 表头（head）：负责维护跳跃表的节点指针。 跳跃表节点：保存着元素值，以及多个层。 层：保存着指向其他元素的指针。高层的指针越过的元素数量大于等于低层的指针，为了提高查找的效率，程序总是从高层先开始访问，然后随着元素值范围的缩小，慢慢降低层次。 表尾：全部由 NULL 组成，表示跳跃表的末尾。 因为跳跃表的定义可以在任何一本算法或数据结构的书中找到， 所以本章不 ...

Redis 通过 MULTI 、 DISCARD 、 EXEC 和 WATCH 四个命令来实现事务功能， 本章首先讨论使用 MULTI 、 DISCARD 和 EXEC 三个命令实现的一般事务， 然后再来讨论带有 WATCH 的事务的实现。 因为事务的安全性也非常重要， 所以本章最后通过常见的 ACID 性质对 Redis 事务的安全性进行了说明。 事务事务提供了一种“将多个命令打包， 然后一次性、按顺序地执行”的机制， 并且事务在执行的期间不会主动中断 —— 服务器在执行完事务中的所有命令之后， 才会继续处理其他客户端的其他命令。 以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令： 12345678910111213141516171819202122redis> MULTIOKredis> SET book-name "Mastering C++ in 21 days"QUEUEDredis> GET book-nameQUEUEDredis> SADD ta ...

一、Redis-Sentinel(哨兵)1、介绍Redis-Sentinel是redis官方推荐的高可用性解决方案，当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。 而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，自动发现master宕机，进行自动切换slave > master。 sentinel主要功能如下： 　　1. 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识　　2. 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也认为主节点不可达，　　 就会选举一个sentinel节点来完成自动故障转移　　3. 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，　　 即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换 2 ...