抽象类和接口的区别

发表于 2019-08-30

含有abstract修饰符的class即为抽象类，abstract 类不能创建实例对象。

含有abstract方法的类必须定义为abstract class，abstract class类中的方法不必是抽象的。

abstract class类中定义抽象方法必须在具体(Concrete)子类中实现，所以，不能有抽象构造方法或抽象静态方法。

如果子类没有实现抽象父类中的所有抽象方法，那么子类也必须定义为abstract类型。

接口（interface）可以说成是抽象类的一种特例，接口中的所有方法都必须是抽象的。

接口中的方法定义默认为public abstract类型，接口中的成员变量类型默认为public static final。

阅读全文 »

字符串在JVM存储位置

发表于 2019-08-30

1. 概述

字符串在 JVM 中如何存放？大多数人能顺利的给出如下答案：

字符串对象在JVM中可能有两个存放的位置：字符串常量池或堆内存。

使用常量字符串初始化的字符串对象，它的值存放在字符串常量池中；
使用字符串构造方法创建的字符串对象，它的值存放在堆内存中；

String提供了一个API, java.lang.String.intern()，这个API可以手动将一个字符串对象的值转移到字符串常量池中

在1.7之前，字符串常量池是在PermGen区域，这个区域的大小是固定的，不能在运行时根据需要扩大，也不能被垃圾收集器回收，因此如果程序中有太多的字符串调用了intern方法的话，就可能造成OOM。

在1.7以后，字符串常量池移到了堆内存中，并且可以被垃圾收集器回收，这个改动降低了字符串常量池OOM的风险。

阅读全文 »

Redis主从复制过程

发表于 2019-08-29

Mybatis防止Sql注入

发表于 2019-08-29

Mybatsi 使用 # 防止 SQL 注入，它将所有传入的参数当作一个字符串来处理，$ 则将传入的参数拼接到 SQL 上执行，一般用于表名和字段名的参数，$ 所对应的参数应该由服务端提供，前端可以用参数选择，避免 SQL 注入的风险。

额外我们还可以通过使用存储过程防止 SQL 注入

原理

为什么 # 可以防止 SQL 注入呢？让我们追踪一下源码。

public interface ClassDao {
  /**
     * 测试 # 和 $ 符号区别
     * @param tableName 表名
     * @param id  主键
     * @return
     */
@Select("select * from ${tableName} where class_id = #{id}")
ClassInfo getByTableNameAndId(@Param("tableName") String tableName,@Param("id")Integer id);
}

源码分析

Mybatis 执行入口是 DefaultSqlSession.selectOne(）方法。我们Debug 启动 testMybatis（）方法，并在 DefaultSqlSession.selectOne()添加断点，一行行执行Mybatis 代码：

一步步向下走，当走到代码： org.apache.ibatis.executor.statement.PreparedStatementHandler#query方法时，可以看到 PreparedStatement 相信大家对这个应该不会陌生，预编译Sql并通过占位符的方式放置参数，现在我们对比一下我们在 Dao 中的 sql ： select * from ${tableName} where class_id = #{id}

如图所示，我们会发现， Mybatis 已经将 sql中 ${tableName} 替换成了 tb_class ，#{id} 也已经变成了占位符？，生成了 Sql ： select * from tb_class where class_id = ?。这已经是一目了然了，Mybaitis 封装了JDBC ,执行时会将我们注解或 Mapper 中的 Sql 和参数进行处理，并交给 PreparedStatement 来执行。

$与#

发表于 2019-08-29

操作系统内存管理

发表于 2019-08-29

Java线程与操作系统线程的关系

发表于 2019-08-29

Linux从内核2.6开始使用NPTL （Native POSIX Thread Library）支持，但这时线程本质上还轻量级进程。

　　Java里的线程是由JVM来管理的，它如何对应到操作系统的线程是由JVM的实现来确定的。Linux 2.6上的HotSpot使用了NPTL机制，JVM线程跟内核轻量级进程有一一对应的关系。线程的调度完全交给了操作系统内核，当然jvm还保留一些策略足以影响到其内部的线程调度，举个例子，在linux下，只要一个Thread.run就会调用一个fork产生一个线程。

　　Java线程在Windows及Linux平台上的实现方式，现在看来，是内核线程的实现方式。这种方式实现的线程，是直接由操作系统内核支持的——由内核完成线程切换，内核通过操纵调度器（Thread Scheduler）实现线程调度，并将线程任务反映到各个处理器上。内核线程是内核的一个分身。程序一般不直接使用该内核线程，而是使用其高级接口，即轻量级进程（LWP），也即线程。这看起来可能很拗口。看图：

说明：KLT即内核线程Kernel Thread，是“内核分身”。每一个KLT对应到进程P中的某一个轻量级进程LWP（也即线程），期间要经过用户态、内核态的切换，并在Thread Scheduler 下反应到处理器CPU上。）

这种线程实现的方式也有它的缺陷：在程序面上使用内核线程，必然在操作系统上多次来回切换用户态及内核态；另外，因为是一对一的线程模型，LWP的支持数是有限的。

　　对于一个大型程序，我们可以开辟的线程数量至少等于运行机器的cpu内核数量。java程序里我们可以通过下面的一行代码得到这个数量：

1	Runtime.getRuntime().availableProcessors();

所以最小线程数量即时cpu内核数量。如果所有的任务都是计算密集型的，这个最小线程数量就是我们需要的线程数。开辟更多的线程只会影响程序的性能，因为线程之间的切换工作，会消耗额外的资源。如果任务是IO密集型的任务，我们可以开辟更多的线程执行任务。当一个任务执行IO操作的时候，线程将会被阻塞，处理器立刻会切换到另外一个合适的线程去执行。如果我们只拥有与内核数量一样多的线程，即使我们有任务要执行，他们也不能执行，因为处理器没有可以用来调度的线程。

如果线程有50%的时间被阻塞，线程的数量就应该是内核数量的2倍。如果更少的比例被阻塞，那么它们就是计算密集型的，则需要开辟较少的线程。如果有更多的时间被阻塞，那么就是IO密集型的程序，则可以开辟更多的线程。于是我们可以得到下面的线程数量计算公式：线程数量=内核数量 / （1 - 阻塞率）

　　我们可以通过相应的分析工具或者java的management包来得到阻塞率的数值。