对象池

什么是长连接？ 其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。 通常的短连接操作步骤是： 连接-》数据传输-》关闭连接 ； 而长连接通常就是： 连接-》数据传输-》保持连接-》数据传输-》保持连接-》…………-》关闭连接 ； 这就要求长连接在没有数据通信时，定时发送数据包，以维持连接状态，短连接在没有数据传输时直接关闭就行了 什么时候用长连接，短连接？ 长连接主要用于在 少数 客户端与服务端的 频繁 通信，因为这时候如果用短连接频繁通信常会发生Socket出错，并且频繁创建Socket连接也是对资源的浪费。 但是对于服务端来说，长连接也会耗费一定的资源，需要专门的线程（unix下可以用进程管理）来负责维护连接状态。 总之，长连接和短连接的选择要视情况而定。 首先，如果使用了长连接而长期没有对数据库进行任何操作，那么在timeout值后，mysql server就会关闭此连接，而客户端在执行查询的时候就会得到一个类似于“MySQL server has gone away“这样的错误。 在使用mysql_real_connect连接数据库之后，再使用mysql_options( &mysql, MYSQL_OPT_RECONNECT, … ) 来设置为自动重连。这样当mysql连接丢失的时候，使用mysql_ping能够自动重连数据库

并发问题产生条件：多个线程同时对共享变量进行读写操作。 解决并发问题，我们平时都是加互斥锁，防止同时进行读写操作，其实换个角度想， 避免共享 ，就可以了。 接下来介绍三种避免共享的三种模式： Immutability 模式、Copy-on-Write 模式和线程本地存储模式。 Immutability 模式（不变性模式） 该模式解决并发问题的思路就是让共享变量只有读操作，没有写操作。即，不变性，**就是创建对象之后，状态就不再发生变化。**变量一旦赋值就不允许赋值。 如何实现不可变性的类？ 将所有的属性都设置成final； 只允许存在只读方法； 如果类的属性是引用型，该属性对应的对象也应该是不可变对象。 不可变对象的应用 其实JAVA SDK中很多类都具备不可变性，比如经常用到的基本类型的包装类Integer,String,Long,Double等，内部都实现了不可变性，其属性都是final类型的，但是你会发现一个问题， 这些类中有存在修改的方法,比如String.replace方法 ，这是怎么回事呢？ String replace ( char oldChar , char newChar ) { 。。。。省略 //创建一个新的字符串返回 //原字符串不会发生任何变化 return new String ( buf , true ) ; } 它是创建了新的String对象返回

Golang在sync里面提供了对象池Pool。一般大家都叫这个为对象池。众所周知，go是自动垃圾回收的，这大大减少了程序编程负担。但gc是一把双刃剑。比如对刚刚上手的程序员是友好的，但是后期随着项目变得越来越巨大，维护的内存问题也会逐渐暴露出来。 sync.Pool是一个可以存或取的临时对象池。对外提供New、Get、Put等API。本文对sync.Pool进行分析。 Pool设计的目的是什么？ Pool 用来保存和复用临时对象，以减少内存分配，降低CG压力。 代码实现 关于代码的实现，最好的办法就是看源代码（src/pkg/sync/pool.go）。 数据结构定义如下： Pool结构体： type Pool struct { noCopy noCopy local unsafe . Pointer // local fixed-size per-P pool, actual type is [P]poolLocal localSize uintptr // size of the local array victim unsafe . Pointer // local from previous cycle victimSize uintptr // size of victims array // New optionally specifies a function to

前言 1965年，荷兰计算机科学家Dijkstra提出的信号量机制成为一种高效的进程同步机制。这之后的15年，信号量一直都是并发编程领域的终结者。1980年，管程被提出，成为继信号量之后的在并发编程领域的第二个选择。目前几乎所有的语言都支持信号量机制，Java也不例外。Java中提供了 Semaphore 并发工具类来支持信号量机制。下面我们就来了解Java实现的信号量机制。 首先介绍信号量模型，然后介绍如何使用，最后使用信号量来实现一个限流器。 信号量模型 信号量模型图（图来自参考[1]）： 信号量模型总结为：一个计数器、一个等待队列和三个对外调用的方法。 计数器和等待队列时对外透明的，所有我们只能通过三个对外方法来访问计数器和等待队列。 init() ：设置计数器的初始值。 down() ：计数器的值减一。如果此时计数器的值小于0，则当前线程插入等待队列并阻塞，否则当前线程可以继续执行。 up() ：计数器的值加一。如果此时计数器的值小于或者等于0，则唤醒等待队列中的一个线程，并将其从等待队列中移除。 这三个方法都是原子性的，由实现信号量模型的方法保证。在Java SDK中，信号量模型是由 java.util.concurrent.Semaphore 实现。 信号量模型代码化大致类似如下： class Semaphore{ int count; // 计数器 Queue

一个Java question，求输出结果 public class IntegerTest { public static void main ( String [ ] args ) { objPoolTest ( ) ; } public static void objPoolTest ( ) { Integer i1 = 40 ; Integer i2 = 40 ; Integer i3 = 0 ; Integer i4 = new Integer ( 40 ) ; Integer i5 = new Integer ( 40 ) ; Integer i6 = new Integer ( 0 ) ; System . out . println ( "i1=i2 \t" + ( i1 == i2 ) ) ; System . out . println ( "i1=i2+i3 \t" + ( i1 == i2 + i3 ) ) ; System . out . println ( "i4=i5 \t" + ( i4 == i5 ) ) ; System . out . println ( "i4=i5+i6 \t" + ( i4 == i5 + i6 ) ) ; System . out . println ( ) ; } } 输出结果是 i1 = i2 true i1 =

👨 前言 本文的主要内容： 介绍享元模式 示例-云盘 总结 源码分析享元模式的典型应用 String中的享元模式 Integer中的享元模式 Long中的享元模式 Apache Common Pool2中的享元模式 享元模式 享元模式(Flyweight Pattern) ： 运用共享技术有效地支持大量细粒度对象的复用 。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，它是一种对象结构型模式。享元模式结构较为复杂，一般结合工厂模式一起使用。 ↘️ 角色 Flyweight（抽象享元类） ：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（ 内部状态 ），同时也可以通过这些方法来设置外部数据（ 外部状态 ）。 ConcreteFlyweight（具体享元类） ：它实现了抽象享元类，其实例称为享元对象；在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象。 UnsharedConcreteFlyweight（非共享具体享元类） ：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类

一：引出问题 在学习字符串的两种比较方式时发现了一个现象，进行一下总结； String str1 = "kaka" ; Srting str2 = "kaka" ; System . out . println ( str1 == str2 ) ; //true 在之前的学习中， String 类型被认为是引用类型，是存放在堆中的，因此在使用" == "判断时，他会将堆内存地址一并进行判断，应该是返回 false 的，为什么返回了 true ？？？。 二：String的两种实例化方式 1：直接赋值 此种方式是最常用的 String str = "kaka" ; 2：使用String的构造方法 String str = new String ( "kaka" ) ; 那么这两种方式有什么不同呢？ 三：引入字符串对象池进行区分 其实开始的问题的造成原因根本上就是由于 字符串对象池（String Pool） 的存在造成的。 JVM为了提高性能和效率，防止不必要的重复创建造成的内存空间的浪费和不断的销毁造成的性能下降，因此创建了String Pool。那么这个字符串对象池是如何提高效率的呢？ 1：使用直接赋值 开始的问题中使用直接赋值的形式进行创建的两个字符串变量。使用"=="进行判断时，会返回true，这就说明这两个值"hello"是来自于同一块内存空间

Apache Commons是一个非常有用的工具包，解决各种实际的通用问题，下面是一个简述表，详细信息访问 http://jakarta.apache.org/commons/index.html BeanUtils Commons-BeanUtils 提供对 Java 反射和自省API的包装 Betwixt Betwixt提供将 JavaBean 映射至 XML 文档，以及相反映射的服务. Chain Chain 提供实现组织复杂的处理流程的“责任链模式”. CLI CLI 提供针对命令行参数，选项，选项组，强制选项等的简单API. Codec Codec 包含一些通用的编码解码算法。包括一些语音编码器， Hex, Base64, 以及URL encoder. Collections Commons-Collections 提供一个类包来扩展和增加标准的 Java Collection框架 Configuration Commons-Configuration 工具对各种各式的配置和参考文件提供读取帮助. Daemon 一种 unix-daemon-like java 代码的替代机制 DBCP Commons-DBCP 提供数据库连接池服务 DbUtils DbUtils 是一个 JDBC helper 类库，完成数据库任务的简单的资源清除代码. Digester Commons

Apache Commons 包含了很多开源的工具，用于解决平时编程经常会遇到的问题，减少重复劳动。项目地址 http://commons.apache.org/ Commons BeanUtils 提供对 Java 反射和自省 API 的包装。 依赖包： Commons Codec 、 Commons Logging Commons Codec 是编码和解码组件，提供常用的编码和解码方法，如 DES 、 SHA1 、 MD5 、 Base64 、 URL 和 Soundx 等。 Commons Collections 是一个集合组件，扩展了 Java 标准 Collections API ，对常用的集合操作进行了很好的封装、抽象和补充，在保证性能的同时大大简化代码。 Commons Compress 是一个压缩、解压缩文件的组件，可以操作 ar 、 cpio 、 Unix dump 、 tar 、 zip 、 gzip 、 XZ 、 Pack200 和 bzip2 格式的压缩文件。 Commons Configuration 是一个 Java 应用程序的配置管理工具，可以从 properties 或者 xml 文件中加载配置信息。 依赖包： Commons Lang 、 Commons Log 、 Commons BeanUtils 、 Commons Collections 、

在 netty引用计数机制 介绍中，我们说到了对象池，这里对对象池做一个详细的介绍。 这里引用上节的内容，介绍下对象池的作用。 对象池其实就是缓存一些对象从而避免大量创建同一个类型的对象，类似线程池的概念。对象池缓存了一些已经创建好的对象，避免需要时才创建对象，同时限制了实例的个数。池化技术最终要的就是重复的使用池内已经创建的对象。从上面的内容就可以看出对象池适用于以下几个场景： 1.创建对象的开销大 2.会创建大量的实例 3.限制一些资源的使用 DirectByteBuffer的缺点在于分配和回收的的代价相对较大，因此DirectByteBuffer适用于缓冲区可以重复使用的场景。 在引用计数变为0的时候，会进行对象的回收，对于池化对象，我们需要将该对象放回到池中，否则会有内存泄露的问题。 内存泄漏：在netty中的内存泄漏是指GC自动回收了refCnt>0的对象的内存，这种情况下使得该对象无法被重建，同时也无法被归还回到netty对象池中，所以即使该内存空置可用，但是应用层仍然标志了该内存被使用中，从而使得该块内存在应用的整个生命周期中无法被使用，造成了浪费。 这里我们来看下netty对象池的实现是怎样的 这里拿PooledByteBuf这个类来作为入口，该类是池化bytebuf所要继承的抽象类，上次我们说到了它的deallocate()方法，用于在引用计数为0后释放资源 如图