一个tomcat应用服务器中只有一个webapp项目名为app，tomcat前面有一个反向代理服务器nginx，nginx将所有访问http://www.example.com/下的请求转发给后台的tomcat应用服务器：http://www.example.com/app/，具体配置如下：

location / {    rewrite ^/(.*)$ /app/$1;    break;}

当前用户已经在http://www.example.com/app/中登录，客户端cookie写入成功，因为是app写入的cookie，所以其作用路径即path=/app/。

当用户访问http://www.example.com/app/some/page页面时，当前的用户session就被重置了，而访问其他页面都是正确的。

检查所在页面的代码，发现页面上有个图片链接因为远程获取用户头像的数据不对，写入的地址变成src="/0"，正确应该是用户的头像地址，就是因为访问了这个错误的地址http://www.example.com/0导致用户的session被重置了。

Concurrency vs. Parallelism

Concurrency和Parallelism是有关系但却又是不同的2个概念：

1. Concurrency: 并发，多个线程同时处理多个任务，多个线程之间有状态共享或者资源共享。
   • 如2个线程竞争CPU。
   • 如2个线程竞争同一个对象锁。
   • 多个GC线程垃圾回收时，对可回收对象进行并发标记，最后并发清理。
   • 并发相对于Serial执行而言，如Serial GC回收。
   • 可以是单核CPU上进行多线程并发执行。
2. Parallelism: 并行，多个线程各做各的事情，多线程间互相间无共享状态。
   • 一个大文件被切分成10个小文件，然后对这个10个小文件并行分析处理。
   • Linus Torvalds还专门在吐槽并行就是未来时提到过，并行计算在GPU图形处理和服务器端上是有用的。
   • 并行重点在于不同线程之间的独立性，无关性。
   • 必须要求是多核CPU。

当JavaScript运行时错误（包括语法错误）发生时，window会触发一个ErrorEvent接口的error事件，并执行window.onerror()，ErrorEvent接口的属性和方法可以参考下面截图。

当一项资源（如<img>或<script>）加载失败，加载资源的元素会触发一个Event接口的error事件，并执行该元素上的onerror()处理函数。这些error事件不会向上冒泡到window，不过在部分浏览器如Firefox中能被window.addEventListener捕获一次。

加载一个全局的error事件处理函数可用于自动收集错误报告。

由于历史原因，window.onerror和element.onerror接受不同的参数。

window.onerror = function(message, source, lineno, colno, error) { ... }
element.onerror = function(event) { ... }

JavaScript因为手机浏览器兼容性的问题，或者用户数据和状态问题导致异常，客户端运行时报错，服务器端有时没有任何错误信息，对bug查找和修复非常不方便，所以将客户端的JavaScript运行异常捕获并上传到后台服务器日志中，并且将错误和用户的会话关联上，可以明确知道哪个用户的手机上抛出了什么错误，便于问题排查。

测试 window.onerror 捕获异常

客户端javascript的异常可以统一由window.onerror进行捕获，并且标准草案定义的也是window.onerror，一般不用window.addEventListener或window.attachEvent的形式去监听window.onerror。

var fn = window.onerror = function () {    console.log(arguments);    // 函数中返回 return true，错误便不会暴露到控制台中。};// 多次注册 error 事件，不会重复执行多个回调// window.onerror 和 addEventListener 都执行了，并只执行了一次window.addEventListener("error", fn);window.addEventListener("error", fn);window.onerror = function (errorMessage, scriptURI, lineNumber, columnNumber, error) {    console.log(arguments);    if (error) {        // 标准草案实现        console.log(error);    } else {        console.log({message: errorMessage, script: scriptURI, line: lineNumber, column: columnNumber});    }}

MySQL中innodb引擎的锁有多种，具体可查看官方文档，这次碰到的死锁与Next-Key Locks没有关系，与Record Locks和Gap Locks有关，下面引用innodb锁的部分文档说明。

Shared and Exclusive Locks

InnoDB implements standard row-level locking where there are two types of locks, shared (S) locks and exclusive (X) locks.

• A shared (S) lock permits the transaction that holds the lock to read a row.
• An exclusive (X) lock permits the transaction that holds the lock to update or delete a row.

git show-branch

git show-branch显示分支和提交的版本情况，下面示例图可以参考此脚本生成。

1. 输出分为上下两部分，使用若干个短划线-分隔。两个分支使用两个短划线-，三个分支使用三个短划线-，依次类推，最多不超过29个分支。
2. 上半部分为层次缩进的分支列表，下半部分为commit列表。
3. 上半部分的分支列表中，使用*标识当前分支，其他分支使用!标识（不同的分支的!标识颜色不一样）。分支前的标识符*或者!一直垂直贯通到下半部分，这一垂直列的符号都是属于这个分支的。
4. 下半部分的commit列表中，前导的符号有*、+和-号:
   1. *表示这一列上的分支(当前分支)有此commit。
   2. +表示这一列上的分支(非当前分支)有此commit。
   3. -表示这是一次合并操作。
5. 标识符的颜色只是用于容易区分列，一个分支一个颜色，如图。

 git show-branch! [br1] v15-br1 ! [br2] v12-br2  ! [br3] v13-br3   * [master] merge br2 into master----   - [master] merge br2 into master + * [br2] v12-br2 + * [br2^] v11-br2 + * [br2~2] v10-br2+  * [br1] v15-br1+  * [br1^] v14-br1+  * [br1~2] v7-br1  +* [br3] v13-br3  +* [br3^] v5-br3   * [master~3] v9-master   * [master~4] v8-master   * [master~5] v6-master  +* [master~6] v4-br3 ++* [master~7] v3-br2+++* [master~8] v2-br1