前面聊闭包的时候提到了不少JavaScript函数表达式的用法。这里补充一个，就是借助函数表达式构建递归函数，因为有一丢丢小坑值得注意一下。

我们先来看一个大家都会写的递归函数：

1
2
3
4
5
6
7

function factorial(num) {
    if (num <= 1) {
        return 1;
    } else {
        return num * factorial(num - 1);
    }
}

上周正好在跟同事一起看了一个跟闭包有一点点相关的小问题，忘性太大，赶紧温习一波。
记得最开始听到”闭包“这个词的时候觉得好高深，但是看英文原词”Closure“就感觉还好诶ˊ_>ˋ

不过在认识闭包之前，我们先要弄清楚两个概念：执行环境(execution context)和作用域(scope)。

执行环境与作用域是什么？

一个变量或函数（在js中，函数的本质也是一个变量）的执行环境定义了它当前可以访问的数据（可以读到什么）和它应有的行为（可以做些什么操作）。每个执行环境都关联了一个变量对象(variable object)，环境中定义的所有变量和函数都保存在这个对象中。

全局环境是指最外层的一个执行环境，根据ECMAScript实现的宿主环境不同，表示全局环境的变量对象也不同。在Web浏览器中，window对象都代表了全局执行环境，所有的全局变量和函数都被创建为window对象的属性和方法。

本期日常：真是一个高(guan)产(shui)的周末呢~

在前面一篇笔记里，我们提到对于查询拿到的ResultSet也是可以进行增删改查操作的，今天就来聊聊这波又是什么操作~

ResultSet与增删改查

默认情况下，一个ResultSet实例是既不可以用于更新操作，也不可以前后随意移动访问数据的，也就是说我们拿到一个默认行为的ResultSet实例就只能调用它的next()方法，依次顺序访问每一行数据。
如果我们要做更复杂的操作，需要前后移动cursor的位置，或者要通过ResultSet做更新操作，就需要在创建Statement实例时指定ResultSet的类型，比如这样：

1

Statement stat = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

本期日常：下雪啦。如果能窝在温暖的房间里，和家人朋友吃着火锅，聊着天，一起欣赏漫天飞舞的雪花，想想就觉得很美好呢。
然而，此刻的我却只能孤独地在冷飕飕的房间里瑟瑟发抖，敲打着冰冷的键盘，流泪～（好啦，并没有(´･ω･`)

上一篇笔记里，我们历经千辛万苦连上了数据库，接下来终于可以愉快地增删改查了～

在JDBC中，有三类SQL语句：

• Statement
• PreparedStatement
• CallableStatement

接下来，我们就来分别看看它们的用途吧~

一个复古的主题，复习一波Java中数据库的基本操作。现在框架用起来这么方便，好多基础的概念都模糊了。

在这个话题下，首先要提到的一个词就是JDBC了，作为一个看到缩写就头大的人，我们就从它开始吧。

JDBC是什么？

数据库的种类这么多，每种数据库都有其特定的协议。如果在开发或者维护Java程序过程中使用的数据库发生了变化，就意味着程序代码要根据特定的数据库进行调整。这个维护成本是非常高的。

而JDBC(Java Database Connectivity)的出现就是为了让开发者能用统一通用的纯Java语言与多种不同的数据库打交道。简单说来，JDBC就是一组用于SQL数据库访问的Java API，采用driver manager来管理和动态绑定driver的机制来连接特定的数据库。

没想到失踪人口回归的第一篇会是它。暂时就放在这里了吧。

本期日常：昨天单抽出了小奶狗超开心，兴奋到决定填坑一篇，结果太激动脑子不太愿意正常运转，只好今天接着填了_(:з」∠)_

在上篇笔记中，我们提到在某些场景下Session-based认证并不是很合适，比如：

1. 如果用户访问量很大，每个用户的session信息都需要保存在服务器端，内存消耗会很大
2. 如果采用分布式部署，创建session的服务器可能和后续处理请求的服务器不同，需要考虑多台服务器session共享的问题
3. 如果不同应用之间要共享认证信息，可能还要考虑跨域问题

除此之外，还有另一个需要考虑的问题：最初用于维持会话的session id一般都会放在cookie中跟随每次请求传到服务端。这对于使用浏览器进行的网页访问是没有问题的，但是，现在很多平台都是直接对外开放API，这些API可能被Web应用请求，也可能被Native移动端应用请求，对于这些应用而言，cookie就不那么友好了。

于是乎，随着需求的不断变化，Token-based认证成为了一个冉冉升起的新星～

我们就从用户名密码认证说起。

认证过程很简单：当客户端访问受保护的API时，需要提供用户名和密码，服务端验证通过后返回请求的资源，否则拒绝访问。

HTTP协议本身就提供了两种基本认证方式。
这两种认证方式的基本流程是一个质询过程：

1. 客户端发送一个HTTP请求给服务器
2. 服务器并不会立即响应请求，而是“认证质询”响应，要求对方提供认证信息
3. 客户端再次发起请求并附上认证信息（比如用户名密码）
4. 如果认证成功，则服务器正常响应，否则再次质询或返回错误

想写Web认证相关的笔记很久了。之前工作内容有部分跟这个主题相关，当时看到的知识点时是非常分散的，一会儿看到底层协议，一会儿看到最佳实践，就感觉内容特别多且杂，导致我相当一段时间都很混乱。

所以这篇笔记，我决定首先从用户交互方式和使用场景来介绍几种基本的认证方式，先搭个框子，更详细的内容以后分模块介绍。

假设一个业务场景，就用我们的甜品店在线订购网站举例吧：

1. 初次光临的用户需要注册账号（用户名、密码等等）
2. 用户登录账号后可下单购买甜品

就一个从这么简单的小站开始，我们决定在第一版网站中采用最原始的认证方式——用户名密码认证。

前面介绍的KMP和Boyer-Moore算法都是基于最基本的字符比较来搜索字符串，这里要介绍的第三种经典算法，其思路与前者完全不同，它就是——Rabin-Karp算法，一个基于Hashing进行字符串搜索的算法。

Rabin-Karp算法主要由两位大师在1987年提出，一位是以色列的Michael O. Rabin，一位是美国的Richard M. Karp。因为其内部哈希函数的实现多采用Rabin提出的Rabin fingerprint算法。Rabin-Karp算法又被称为”the Fingerprint Method”。

基于Hashing搜索字符串，这么简单的一句话，就涵盖了Rabin-Karp算法的主要思想。

给定长度为M的目标字符串pattern和长度为N的文本text，采用某种Hash函数计算出pattern的Hash值P，然后遍历text，计算每段长度为M的子串的Hash值Q，如果P等于Q，那么就匹配成功。

这里面最重要的问题就是如何选择Hash函数：

1. 如果Hash函数本身的计算成本太高，也会降低效率；
2. 如果Hash函数的冲突率太高，那么对于两个Hash值相同的字符串我们并不敢相信它们是相同的，最纵横还是会需要挨个进行字符比较，Hash值也就失去其意义所在，最差的情况下时间复杂度会达到O(MN)，甚至比暴力解决更慢（因为计算Hash值也要时间）。