阶段性笔记

日常笔记

2016/7/4

asm：java字节码操作框架

asm bytecode-outline插件

java instrumentation机制

premain机制

通过添加插件maven-jar-plugin指定MANIFEST.MF的属性值

java热部署

2016/7/5

java se 6新特性：premain agentmain动态native方法替换动态classpath替换

jmockit原理了解ing

agentmain机制 无需指定jvm参数 程序中动态加载

2016/7/6

了解fastdev.jar热部署原理。

Linux网络相关命令：

Curl & wget

Ping

tracepath & traceroute

mtr

host

whois

ifplugstatus

ifconfig

ifdown & ifup

dhclient

netstat

jvm参数 –noverify说明运行前不对class进行校验。

2016/7/12

Pandora学习中 类加载机制。

2016/7/13

HSF学习ing

2016/7/14

HSF学习ing

Spring ApplicationListener使用。ApplicationContextAware触发早于InitializingBean。

java.util.ServiceLoader使用。

单例模式静态内部类的实现方式。

2016/7/15

test-classloader demo

2016/7/26

ClassLoader

实现自己的classloader，如果需要打破双亲则重新loadClass，否则重写findClass即可。

APP、EXT类加载器继承ClassLoader；Boot不继承。

2016/7/28

java类型检测导致的类提前加载（当前类的类型检测）

提前加载的场景：

1.当代码中出现方法接收的参数类型为方法参数定义类型的子类时，那么参数类型和子类，将会优先进行加载，甚至早于方法所在类的static块。因为Java需要判定这个方法是否可以接收这个类型，着重点在验证方法参数类型之间的继承关系

2.当一个类的成员变量被赋值一个子类型时，该成员变量的类型和子类型将会优先于成员变量所在类进行加载。 3.当一个类中包括的方法，返回的类型是形参的子类时，形参和返回参数的子类型将会提前加载。

-verbose:class可查看类从哪儿被加载。

2016/8/11

Jstorm-概念及应用场景

Maven插件maven-shade-plugin将依赖的jar包统一打成一个包。

2016/8/12

Java I/O netty

Linux对外部设备都看为文件，文件的读写操作会调用系统内核的命令，返回fd，对socket的读写返回socketfd。

I/O模型分类：

1.    阻塞I/O模型

2.    非阻塞I/O模型

3.    I/O复用模型

4.    信号驱动I/O模型

5.    异步I/O模型

I/O多路复用技术：

支持I/O多路复用的系统调用包括select、pselect、poll、epoll。

Select和epoll的主要区别于select是轮询，而epoll是基于事件驱动的。

Epoll相对于select的优点在于：

1.    支持一个进程打开的socketfd不受限制（仅限于操作系统最大句柄数）

2.    效率不会随着FD的数据增加而线性下降。

3.    mmap

4.    epoll的api简单

jdk1.4 Java NIO 对应于五大模型中的多路复用模型

NIO中最重要的就是多路复用器selector

jdk1.7 Java AIO （NIO2.0）对应于五大模型中的信号驱动模型。

 

Netty优点：

2016/8/15

TCP粘包拆包

粘包问题的解决策略：

1.    消息定长，不够通过空位补齐

2.    包尾添加特殊标记，如回车换行 FTP、HTTP

3.    消息头和消息体消息头包含数据包总长度

4.    。。。

Netty解决粘包拆包的两个解码器：LineBasedFrameDecoder、StringDecoder.

Java序列化的目的有两个：

1.    网络传输

2.    对象持久化

Java序列化由jdk1.1开始提供，无需依赖额外类库，实现序列化接口并生成序列化ID即可。

评判一个编解码的优劣由以下几点：

1.    是否支持跨语音

2.    编码后码流大小

3.    编解码性能

4.    类库小巧，API方便易用

5.    使用者手动开发的工作量和难度

 

但一般的RPC很少直接使用java序列化，其原因如下：

1.    无法跨语言

2.    序列化后码流偏大

3.    序列化性能太低

 

主流的编解码框架：

1.    Google Protocol Buffers

为什么不使用XML，尽管XML可读性和可扩展性都很好，但带来的是解析的时间开销和存储的空间开销都非常大，不适用做高性能的通信框架。使用二进制编码。

2.    Jboss Marshalling

 

ByteBuffer的内存有两种内存：

1.    堆内存

内存分配和回收速度快，可被JVM自动回收。但进行Socket I/O读写需要额外做一次内存拷贝。将堆内存对应的缓冲区复制到内核。

2.    直接内存

内存分配和回收速度慢，但是socket I/O不需要内存拷贝，速度快。