杂谈（四）

Jitorun
120 阅读11分钟

mysql去重（超大数据量）

  • 可以采用set，set底层使用红黑树来实现，O（logn），但是当字符串较长且相似时效率非常低

  • 因此进一步可以采用hash，比如hashtable，但是存在hash冲突，需要选择具有强随机分布性的hash函数

  • 再进一步可以采用布隆过滤器（概率型数据结构），前文中set利用key唯一，hash利用hashcode，布隆过滤器不存储具体元素，能告诉我们哪个key明确不存在，但是某个字符串不存在，可能判定为存在，可能存在误差

    • 采用位图+hash函数
    • 当数据量以亿级时，占用空间也大

  • 进一步可采用hyperloglog，HyperLogLog实际上不会存储每个元素的值，它使用的是概率算法，通过存储元素的hash值的第一个1的位置，来计算元素数量。对于一个输入的字符串，首先得到64位的hash值，用前14位来定位桶的位置（共有 [公式] ，即16384个桶)。后面50位即为伯努利过程，每个桶有6bit，记录第一次出现1的位置count，如果count>oldcount，就用count替换oldcount

    • 代码实现较难。
    • 能够使用极少的内存来统计巨量的数据，在 Redis 中实现的 HyperLogLog，只需要12K内存就能统计2^64个数据。
    • 计数存在一定的误差，误差率整体较低。标准误差为 0.81% 。
    • 误差可以被设置辅助计算因子进行降低。

总结

  • 针对时间，我们可以采用巧妙的算法搭配合适的数据结构，如Bloom filter/Hash/bit-map/堆/数据库或倒排索引/trie树
  • 针对空间，无非就一个办法：大而化小，分而治之（hash映射），把规模大化为规模小的，各个击破

lambda表达式对比匿名内部类

匿名内部类： 顾名思义就是没有名字的定义在另一个类中的内部类，只能使用一次，通常用来简化代码编写，如果一个类只用了一次，那么单独为其创建一个类很浪费，匿名内部类的前提是存在继承或实现关系的

Java中的匿名内部类只可以访问final的局部变量

因为生命周期不一致， 局部变量直接存储在栈中，当方法执行结束后，非final的局部变量就被销毁。而内部类对局部变量的引用依然存在，如果内部类要调用局部变量时，就会出错。加了final，可以确保局部内部类使用的变量与外层的局部变量区分开，解决了这个问题。

以及数据一致性，用final修饰实际上就是为了保护数据的一致性。这里所说的数据一致性，对引用变量来说是引用地址的一致性，对基本类型来说就是值的一致性。究其原因，在于区域变量 x 并不是真正被拿来于匿名内部类中使用，而是在内部匿名类别中复制一份，作为field成员来使用，由于是副本，即便你在匿名内部类中对 x 作了修改，也不会影响真正的区域变量 x，事实上您也通不过编译器的检查，因为编译器要求您加上"final"关键词，这样你就知道你不能在内部匿名类别中改变 x 的值

Lambda：省略 new 接口名，简化为 () -> {... }

双亲委派模型

双亲委派.png

  • 启动类加载器（Bootstrap ClassLoader）：这个类加载器复杂将存放在 JAVA_HOME/lib 目录中的，或者被-Xbootclasspath 参数所指定的路径种的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录下也不会重载）。
  • 扩展类加载器（Extension ClassLoader）：这个类加载器由sun.misc.Launcher$ExtClassLoader实现，它负责夹杂JAVA_HOME/lib/ext 目录下的，或者被java.ext.dirs 系统变量所指定的路径种的所有类库。开发者可以直接使用扩展类加载器。
  • 应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是ClassLoader 种的getSystemClassLoader方法的返回值，所以也成为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库。开发者可以直接使用这个类加载器，如果应用中没有定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委派父类加载器去完成。每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启

为什么要这么做：如果没有使用双亲委派模型，由各个类加载器自行加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会出现多个不同的Object类， Java类型体系中最基础的行为就无法保证。应用程序也将会变得一片混乱。

如何实现：所有的代码都在java.lang.ClassLoader中的loadClass方法之中，先检查是否已经被加载过，若没有加载则调用父加载器的loadClass方法， 如父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException 异常后，再调用自己的findClass方法进行加载。

Tomcat打破双亲委派

Tomcat的自定义类加载器WebAppClassLoader打破了双亲委托机制： 首先自己尝试去加载某个类，如果找不到再委托给父类加载器，目的是优先加载Web应用自己定义的类。

Tomcat是个web容器， 那么它要解决什么问题：

  1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
  2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。
  3. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
  4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。

Tomcat 如果使用默认的类加载机制行不行？ 答案是不行的。为什么？我们看，第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题，我们想我们要怎么实现jsp文件的热修改（楼主起的名字），jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

其他打破双亲委派模型

JDBC:在JDBC 4.0之后实际上我们不需要再调用Class.forName来加载驱动程序了，我们只需要把驱动的jar包放到工程的类加载路径里，那么驱动就会被自动加载。

这个自动加载采用的技术叫做SPI，数据库驱动厂商也都做了更新。可以看一下jar包里面的META-INF/services目录，里面有一个java.sql.Driver的文件，文件里面包含了驱动的全路径名。

SPI的优势在能够自动的加载类到JVM内存,为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。

为什么要打破模型呢？

因为类加载器受到加载范围的限制，在某些情况下父类加载器无法加载到需要的文件，这时候就需要委托子类加载器去加载class文件。

JDBC的Driver接口定义在JDK中，其实现由各个数据库的服务商来提供，比如MySQL驱动包。DriverManager 类中要加载各个实现了Driver接口的类，然后进行管理，但是DriverManager位于 JAVA_HOME中jre/lib/rt.jar 包，由BootStrap类加载器加载，而其Driver接口的实现类是位于服务商提供的 Jar 包，根据类加载机制，当被装载的类引用了另外一个类的时候，虚拟机就会使用装载第一个类的类装载器装载被引用的类 也就是说BootStrap类加载器还要去加载jar包中的Driver接口的实现类。我们知道，BootStrap类加载器默认只负责加载 $JAVA_HOME中jre/lib/rt.jar 里所有的class，所以需要由子类加载器去加载Driver实现，这就破坏了双亲委派模型。

查看DriverManager类的源码，看到在使用DriverManager的时候会触发其静态代码块，调用 loadInitialDrivers() 方法，并调用ServiceLoader.load(Driver.class) 加载所有在META-INF/services/java.sql.Driver 文件里边的类到JVM内存，完成驱动的自动加载。

泛型

泛型的作用是一种安全机制，是一种书写规范，它和接口的作用有着一定的类似，都是在制定规则。

底层其实都是Object（泛型擦除）

Restful

RESTful架构风格规定，数据的元操作，即CRUD(create, read, update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作。

即：

  • GET（SELECT）：从服务器取出资源（一项或多项）。
  • POST（CREATE）：在服务器新建一个资源。
  • PUT（UPDATE）：在服务器更新资源（客户端提供完整资源数据）。
  • PATCH（UPDATE）：在服务器更新资源（客户端提供需要修改的资源数据）。
  • DELETE（DELETE）：从服务器删除资源。

可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。

一般的，每个资源至少有一个URI与之对应，最典型的URI即URL。

运行时估算一个对象的大小

　对于按对象尺寸管理的cache,由于Java对象的实际内存大小不好获得，所以一般就使用一个Serializable对象的序列化尺寸来代替，序列化时通常把一个对象序列化到一个字节buffer里，那么就可以获得这个buffer的字节数。

也可以就是每次分配对象利用面向切面编程或者写屏障的思想，去计算每个偏移量上的数据类型，据此估计一个对象的大小。

常用数据源

DataSource 通常被称为数据源，它包含连接池和连接池管理两个部分，习惯上也经常把 DataSource 称为连接池。

1、 DBCP： DBCP(DataBase connection pool)数据库连接池。是apache上的一个 java连接池项目，也是 tomcat使用的连接池组件。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar由于建立数据库连接是一个非常耗时耗资源的行为，所以通过连接池预先同数据库建立一些连接，放在内存中，应用程序需要建立数据库连接时直接到连接池中申请一个就行，用完后再放回去。dbcp没有自动的去回收空闲连接的功能。

2、 C3P0： C3P0是一个开源的jdbc连接池，它实现了数据源和jndi绑定，支持jdbc3规范和jdbc2的标准扩展。c3p0是异步操作的，缓慢的jdbc操作通过帮助进程完成。扩展这些操作可以有效的提升性能。目前使用它的开源项目有Hibernate，Spring等。c3p0有自动回收空闲连接功能。

3 、druid：

Druid是一个开源项目，源码托管在github上，源代码仓库地址是 github.com/alibaba/dru… 。

\

avatar
文章
阅读
粉丝