很不错的一本书，作为程序员都值得去看一看，170+页周末一天可以看完， 还包括做笔记

医学专业已经建立起一套严密的辅导体系
软件行业建立一种包含学徒期、实习期、和长期指引的机制已是迫在眉睫

有人指导大多数人都可以快速的成长，节省很多走弯路的时间
当然，事在人为，只是说掌握了书中的那些要领，成为专业人员的几率更高，做更好的自己
如果从小学开始就一直有人引路并且自己也愿意跟着走的话，应该会很棒，现在也不晚，抓住时间就好

主要内容：
专业主义
学会说“不”，学会说“是”
编码的正确姿势
TDD
卡塔练习很重要，肌肉反应
验收测试(各方都一致同一的检验方式)
测试策略，自动化测试是趋势
时间管理，番茄工作法，注意力点数
预估的概念以及方法
压力，避免与面对
协作，学会与人交流
团队与项目，有凝聚力的团队战斗力强
软件开发如医生一样培训更佳
合适的工具事半功倍

一、背景

业务当中多处用到线程池进行异步处理;
为了得知线程池设置是否合理，故需要增加线程池监控;
常见的实现方式：

1. org.springframework.scheduling.concurrent.ScheduledExecutorTask
2. org.springframework.scheduling.annotation.Scheduled

本文使用1的方式实现，主要是方便进行配置，可以托管多个任务;

二、效果预览

1
2
3

taskName:pool1-monitor. taskCount:820, completedTaskCount:820, largestPoolSize:30, poolSize:30, activeCount:0, corePoolSize:30, maximumPoolSize:50, queueSize:0
taskName:pool2-monitor. taskCount:1703, completedTaskCount:1703, largestPoolSize:30, poolSize:30, activeCount:0, corePoolSize:30, maximumPoolSize:50, queueSize:0
taskName:pool3-monitor. taskCount:820, completedTaskCount:448, largestPoolSize:30, poolSize:30, activeCount:30, corePoolSize:30, maximumPoolSize:50, queueSize:342

三、监控逻辑

代码如下:

一、内容简介

这是一本人类大脑可塑性研究先驱与翘楚的故事书，正是让我们用触觉看到世界的巴赫-利塔这类先驱，使得我们正在成为来自地球的神。

二、读后感

这本书对我来讲还是很棒的，刷新了我对大脑的认知;
以前还停留在左右脑分工上，殊不知这是日本鬼子整出来的不严谨的概念;
看完书，感觉对个人技术、学习方面都有帮助，增加信心，因为之前错过了学校的大把学习时间;
运动和学习是互补的，前者产生新的神经干细胞，后者使它们的寿命延长;

这本书我是很推荐看的;
犹如最近看完的reids英文版文档;
每天看一点点，持续的刺激大脑相关区域，收获还是可以;
之前也咨询过英语比较好的同事;
反馈说目前想提高，就拿着领域内的文档硬看，坚持下来会有收获的;

每次看完书都会发个微博，避开朋友圈的尴尬，扩大散播范围，与更多的同好交流;

三、内容摘要

《重塑大脑，重塑人生》0822～0901
在持续不断噪声环境中长大的孩子都好动和吵闹，白噪声对大脑发育也有影响。

零、相关介绍

关键错误信息：
java.lang.RuntimeException: RESTeasy Provider Factory is null, do you have the ResteasyBootstrap listener configured?
java.lang.RuntimeException: Illegal to inject a message body into a singleton into public com.alibaba.fastjson.support.jaxrs.FastJsonProvider(java.lang.String)

resteasy:JBoss的一个开源项目，提供一套完整的框架帮助开发人员构建RESTful Web Service和RESTful Java应用程序。
fastjson:由阿里开发的一个性能很好的Java JSON 解析器和生成器。

引起错误的依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.58</version><!--改为：1.1.34.sec01相安无事-->
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-jaxrs</artifactId>
    <version>2.2.1.GA</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>jaxrs-api</artifactId>
    <version>2.2.1.GA</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-spring</artifactId>
    <version>2.2.1.GA</version>
</dependency>

一、错误日志

本地启动Server报错

零、本文背景

一个接口的关键指标应该就是响应速度，要想提高响应速度，结果在缓存中最好;
所以通过查询时间与缓存中订单的时间进行对比，得出缓存过期时间的最佳值，以平衡性能与成本;
近期在做日志分析，找到比较理想的一个缓存过期时间，使90%的查询都能被缓存覆盖;

ps：提取日志的关键是要日志规范，方便切割，才好算出调用时间(适用于暴利分析，而不是通过调用链等方式)；

一、性能指标含义

常见指标：TP50、TP90、TP99、TP999
正式解释：TP=Top Percentile，Top百分数，是一个统计学里的术语，与平均数、中位数都是一类;
通俗理解：TP99 100ms，99%的查询都能在100ms内返回;

二、性能指标计算

计算方式：拿100次调用的耗时，排序，取第99个的耗时，这就是TP99的值;

具体的代码方式就是，先算出耗时，放入List，然后排序，按指定的下标取值即可;

代码如下：

零、本文背景

项目中看到有一个缓存接口存在多个实现类,
但是在代码中使用@Resource注解注入,
之前有了解过@Autowire @Resource的区别,
于是就尝试着搜索@@Resource，于是就有本文的总结了。

一、两个注解

1.1 @Autowire

1.1.1 Spring开发;
1.1.2 按照type来注入;

1.2 @Resource

1.2.1 JDK开发；
1.2.2 按照名称注入，若无，则按type来注入(未指定name的情况下);

二、后记

1. 做事情要有计划，得主动;
2. 需要想清楚自己想要什么样的生活，然后朝着目标奋斗;
3. 使用现成的代码尽量搞清楚来龙去脉，可以学习知识，更能避免被坑;
4. 每天的学习时间需要保证，坚持很重要;

零、本文由来

感觉从业这么久以来，读取文件路径相关问题一直是一个痛
用的很少，之前也解决过相关的问题
但是得用这种路径

1

src/test/resources/test/test.txt

上面这种路径如果在代码中的话，src/test/resources是不会存在的，会出现问题
本次学到了一个新的方法，Class.getResourceAsStream();
需要的路径在资源文件夹下面即可，填写路径：/test/test.txt
打包最终的路径会在：WEB-INF/classes/test/test.txt

ps：因maven打包配置不同，最终resources资源文件夹下的路径是不同的，注意src的坑即可

一、文件结构

1
2
3
4
5
6
7

│   └── test
│       ├── java
│       │   └── mq
│       │       └── Test.java
│       └── resources
│           ├── test
│           │   └── test.txt

二、读取代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@RunWith(value = SpringJUnit4ClassRunner.class)
@ContextConfiguration({"/spring-config.xml"})
public class Test {
    @Test
    public void test() throws IOException {
        InputStream inputStream = Test.class.getResourceAsStream("/test/test.txt");
        byte[] buffer = new byte[1024];
        int len;
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        while ((len = inputStream.read(buffer)) != -1) {
            bos.write(buffer, 0, len);
        }
        bos.close();
        String res = bos.toString();
        System.out.println(res);
    }
}

一、volatile是什么

volatile是Java提供的一种轻量级的同步机制
保证变量的修改其它线程立马可见，解决部分并发问题

二、volatile局限性

无法解决复合操作，例如 i++ i–这种操作
原因：i++操作分三步

1. 读取i=1；
2. i=i+1=2；
3. i=2写入主存
   有可能在3写入之前，其它线程已经对i进行了修改，比如改为100了，结果覆盖写入了2

三、volatile原理

volatile底层依靠指令重排序来实现内存可见性的
具体的规则如下

1. 当第二个操作是voaltile写时，无论第一个操作是什么，都不能进行重排序
2. 当第一个操作是volatile读时，不管第二个操作是什么，都不能进行重排序
3. 当第一个操作是volatile写时，第二个操作是volatile读时，不能进行重排序

ps：时间比较仓促，写的比较粗糙，后期再优化；

一、为什么用缓存

1.1 空间换时间：

缓存是针对读多写少的场景典型的以空间换时间的操作
空间：内存
时间：读内存速度快(相对于读磁盘)

1.2 局部性原理：

这个世界很多事情都符合28原则
把热点数据缓存起来就大大提高系统效率

二、缓存组件选择

2.1 Ecache

1. 快速，针对大型高并发系统场景，Ehcache的多线程机制有相应的优化改善;
2. 简单，很小的jar包，简单配置就可直接使用，单机场景下无需过多的其他服务依赖;
3. 支持多种的缓存策略，灵活;
4. 缓存数据有两级：内存和磁盘，与一般的本地内存缓存相比，有了磁盘的存储空间，将可以支持更大量的数据缓存需求;
5. 具有缓存和缓存管理器的侦听接口，能更简单方便的进行缓存实例的监控管理;
6. 支持多缓存管理器实例，以及一个实例的多个缓存区域;

2.2 Guava

1. 自动将entry节点加载进缓存结构中；
2. 当缓存的数据超过设置的最大值时，使用LRU算法移除；
3. 具备根据entry节点上次被访问或者写入时间计算它的过期机制；
4. 缓存的key被封装在WeakReference引用内；
5. 缓存的Value被封装在WeakReference或SoftReference引用内；
6. 统计缓存使用过程中命中率、异常率、未命中率等统计数据;

2.3 Memcache

1. memcache使用预分配内存池的方式管理内存;
2. 所有数据存储在物理内存里;
3. 非阻塞IO复用模型，纯KV存取操作;
4. 多线程，效率高，会遇到锁等，上下文切换问题;
5. 只支持简单KV数据类型;
6. 数据不支持持久化;

2.4 Redis

1. 临时申请空间，可能导致碎片;
2. 有VM机制，能存储更多数据，超过内存空间后会导致swap，降低效率;
3. 非阻塞IO复用模型，支持额外CPU计算：排序、聚合，会影响IO性能;
4. 单线程，无锁，无上下文切换，单实例无法利用多核性能;
5. 支持多种数据类型：string / hash / list / set / sorted set
6. 数据支持持久化：AOF(语句增量)/RDB(fork全量)
7. 天然支持高可用分布式方案sentinel + cluster(故障自动转移+集群)

三、正确使用缓存

3.1 读场景：先读缓存、再读DB

如果是并发读缓存失效，使用分布式锁只允许单次查询，其它等待，超时返回失败

一、理论知识

常见参数：

1. -Xms 堆初始化 例如：-Xms256m
2. -Xmx 堆最大值 例如：-Xmx512m
3. -Xmn 堆新生代 例如：-Xmn100m
4. -XX:NewRatio 新生代与老年代的比例
5. -XX:SurvivorRatio 新生代区域比例，默认8,代表Eden:From Survivor:To Survivor = 8:1:1

垃圾回收器：

1. Serial/Serial Old 新生代/老年代，古老，单线程，暂停所有用户线程，复制算法/标记整理算法
2. ParNew 1的多线程版本
3. Parallel Scavenge 新生代，多线程，不需要暂停用户线程，复制算法
4. Parallel Old 老年代，多线程，不需要暂停用户线程，标记整理算法
5. CMS（Current Mark Sweep，详情）老年代，与ParNew配合使用，牺牲吞吐量获得最短停顿，标记整理算法
6. G1 并行与并发收集器，可预测的停顿时间

二、实践案例

1. Full GC 之前进行 Minor GC 避免扫描过多的对象， 配置：CMSScavengeBeforeRemark
2. Xms和Xmx设置为相同，这样可以减少内存自动扩容和收缩带来的性能损失
3. JVM调优是最后的稻草，进行JVM调优之前应该先优化架构和代码
4. 调优是一个复杂的过程，根据具体的场景结合对垃圾回收器的深入理解进行调优，才可能事半功倍。

各个区大小比例建议

1
2
3
4
5

# 活跃空间大小：Full GC后堆中老年代占用空间的大小
空间      倍数
总大小    3-4倍活跃空间大小
新生代    1-1.5倍活跃空间大小
老年代    2-3倍活跃空间大小