在前面我们的 Backbone.js 用上了 Model, 但绝大数的情况下我们处理的都是一批的 Model 数据列表，所以需要有一个 Collection 来容纳 Model, 就像 Java 里最常用的 List。
声明 Collection 时需要指定他处理的 Model 类型，也就是个泛型参数，如我们这样定义 Collection:
然后就是往 Collection 中如何填充 Model 实例，有好多种，这里只演示最直接的方式。还 add, fetch, 及对 Collection 排序, 遍历等各种操作。 阅读全文 >>
早先对 Java ArrayList 的扩容理解是在 new ArrayList() 时会默认建立一个内部容量为 16(这个数值还是错的，往后看) 大小的数组，然而插入数据容量不足时会扩容为原来的 1.5 倍，并用 System.arraycopy() 移动原来的数组到新的大数组中，所以为了频繁的内部扩容操作，在已知 ArrayList 将来大小的情况下，应该在创建 ArrayList 时指定大小，如 new ArrayList(1000)。那么是否指定初始容量对性能会有多大的影响仍缺乏感性的认识。
本文通过具体的测试主要掌握以下知识
就像 JDK 8 的 HashMap 引入了红黑树改善性，随着 JDK 版本的升级 ArrayList 的内部实现也在演进。回到 JDK 7, 当我们不指定容量 new ArrayList() 创建一个对象时的实现是 阅读全文 >>
看国内的一些项目时 Dubbo 这个词经常闪现，一直也不以为然，未作搜索，当然也不知道它是做什么用的。直到最近阅读关于大型网站架构相关的书中反复提到 Dubbo 后，觉得不能再对它视而不见。Google 了一下，它是在阿里巴巴创建贡献给了 Apache 的开源项目，在阿里巴巴的大型应用中久经考验过的。Dubbo 是什么呢？借用官方 Dubbo 介绍
Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。
Dubbo 是国内企业贡献的，所以官方有原生的中文文档，它某些时候与 Spring Cloud 齐名，又有些像 AWS 的 ECS Service Discovery, Service Connect 加上 ELB 的功能。 阅读全文 >>
我们通常用的 Java 缓存基本可认为是扩展了 HashMap 或 ConcurrentHashMap 的实现，它们各自实现自己的缓存策略，如时间与空间的控制，生命周期管理，是否支持分布式，溢出时能否转储到磁盘。关于 Java 本地缓存的存储分为内存与磁盘，内存多数情况下指的是堆内内存(on-heap), 而介于堆内内存与文件存储之间的就是堆外内存(off-heap)
我们查看一下当前 Spring 支持的缓存实现, Supported Cache Providers, 列有 Generic, JCache(JSR-107), EhCache 2.x, Hazelcast, Infinispan, Couchbase, Redis, Caffeine, Simple， 这其中无一支持堆外缓存，其中的 EhCache 要付费使用 EhCache 3(Big Memory) 才能支持 off-heap。 阅读全文 >>
终于来到了 Rust 的精髓所在了，那就是使之不依赖于垃圾回收又能保障内存安全且高效运行的所有权系统(Ownership System)。想要用 Rust 做一个稍显规模项目必定绕不过它，所有权系统包括所有权(Ownership), 借用(Borrowing), 生命周期(Lifetimes)。
以下概念的复述基本是从 《Rust编程: 入门, 实战与进阶》一书中而来，那里面有些内容是来自于官方的 The Rust Programming Languge - Understanding Ownership.
Rust 的编程语法很快就能上手，让学习 Rust 曲线陡然大增的也就是这个所有权系统。所有权检测在编译期完成，Rust 能编译出来的代码就是安全高效的。要理解 Rust 的所有权系统必须首先明白以下两组概念：
和其他语言一样，大小固定的所有基本类型都可以存储在栈上，栈上存取数据总是在栈顶操作，很快，而访问堆内存需要搜索内存地址。所有权系统的主要任务是用来跟踪堆上的数据，即引用语义的数据。 阅读全文 >>
觉得还是有必要继续深入学习一下 Rust 再练手，毕竟仍然看到 & 和 * 符号还有些恍惚，大概就是 C/C++ 里的取地址和取值操作吧，实际上也确实类似。只是叫法略有不同, 还有就是在 C/C++ 多用了指针的概念。
在 C/C++ 中， &：称作 Address-of Operator, 在 Rust 中称作 Reference Operator, 而 * 在 C/C++ 和 Rust 中都叫做 Dereference Operator。以前学 C/C++ 经常被一系列的 &, * 打晕了头，如今参考了它们的英文名称立刻变得清晰了起来。
就像当初看汇编各种寻址方式弄得头都大了，其实也就是依照约定。 阅读全文 >>
再继续快速学习一下 Rust 的以下几个知识点，就可以开始着手做点小工具了
Rust 设计为有效使用内存考虑的，它提供了非常细力度的数据类型，如整数分为有无符号，宽度从 8 位到 128 位，分别表示为 i8, u8, u128 等。浮点数有 f32 和 f64，以及 bool 和 range 类型。
元组和 Python 的元组用法类似，Immutable, 可混合类型
数组类型中的元素类型相同，表示为 [T; n], T 为类型，n 为元素个数 阅读全文 >>
本篇同样是阅读《100 Java Mistakes and How to Avoid Them》的一则笔记，只是火力全集中在 StackOverflowError 这个单一主题之上, 且主要与递归及尾递归优化相关。一提到 StackOverflow, 恐怕首先是想到那个代码搬运源网站 stackoverflow.com，其次才是代码执行过程中的 StackOverflowError 错误。
什么是 StackOverflow, 准确来说是指线程的栈内存不足，无法在栈中分配新的内存(或创建新的栈帧)。我们通常会把它与方法调用关联起来，因为一次方法调用会创建一个新的栈帧，分配在栈上的局部变量(包括基本类型与对象引用)，和栈帧都要占用线程栈内存。而我们平时所说的方法调用栈，或出现异常时打印出的异常栈都是一个概念。
StackOverflowError 一般出现在方法调用太深(方法调方法)，手动编写的方法调用一般不容易达到这个限制，所以它与递归调用关系最为密切，递归调用次数太多或甚至没有出口条件无限递归; 也可能是经过一番递归调用后，再正常调用后续方法时出现 StackOverflowError(因为前面的递归调用资源消耗的差不多)
何谓递归调用，简单的说就是方法自己调用自己，从而实现循环的效果，或使代码更精练，例如经典排序中的快速和归并排序就要用到递归。但循环与递归又有本质上的区别，循环不增加调用深度；递归却不同，递归分递进与回归两个过程，递进调用时每次调用前都需通过压栈来保留现场，逆向回归时再逐级恢复现场，保留现场的过程就要从线程栈中分配内存空间; 死循环可能不会造成程序异常，但死(无限)递归必定出现 StackOverflowError。 阅读全文 >>
本书的阅读又搁置了许久，虽然感觉 Manning 出版社的这一 100 Mistakes 系列从书的质量不是那么的高，但开了头还是继续从本书 40% 的位置往下。
开始要讲述到异常了，异常还是有必要认真对待的，比如
Java 的主要异常大分类是
Throwable
├── Error
└── Exception
└── RuntimeException
NullPointerException, 这恐怕是一个最常见的异常，Java 对一个对象是否能为 null 值没什么约束，甚至用 null 来表示业务上的空。比如说方法的参数与返回值，Java 都可以是 null 值，而在 Kotlin 中非明确可为 null 的时不能为 null 阅读全文 >>
这几日在阅读 Manning 出版社的 《100 Java Mistakes and How to Avoid Them》, 其中列举的确实是一些容易带入到代码中的错误，不少还是通过代码 Review 或单元测试很难发现的问题。也有些看似很弱智，却可能是隐匿许久的定时炸弹，只等某一特定条件出现时即爆。
阅读的同时简单的作了笔记及少许联想，所以内容有些杂乱无条理。最前面介绍了一些静态代码分析工具，也有两个动态分析工具。本书目前还是 Manning 的 MEAP 体验版，未正式发售。一共讲了 100 个常见错误如何避免(例如，怎么用最新 Java(Java 9 -- Java 21) 语法, API 来改进)，以及用静态分析工具，单元测试及早发现。
这是读完了 1/4 数量的记录，笔记开始 阅读全文 >>
Notifications