源码分析

cond的主要作用就是获取锁之后，wait()方法会等待一个通知，来进行下一步锁释放等操作，以此控制锁合适释放，释放频率,适用于在并发环境下goroutine的等待和通知。 针对Golang 1.9的sync.Cond，与Golang 1.10一样。 源代码位置：sync\cond.go。 结构体 type Cond struct { noCopy noCopy // noCopy可以嵌入到结构中，在第一次使用后不可复制,使用go vet作为检测使用 // 根据需求初始化不同的锁，如*Mutex 和 *RWMutex L Locker notify notifyList // 通知列表,调用Wait()方法的goroutine会被放入list中,每次唤醒,从这里取出 checker copyChecker // 复制检查,检查cond实例是否被复制 } 再来看看等待队列 notifyList 结构体： type notifyList struct { wait uint32 notify uint32 lock uintptr head unsafe.Pointer tail unsafe.Pointer } 函数 NewCond 相当于 Cond 的构造函数，用于初始化 Cond 。 参数为Locker实例初始化,传参数的时候必须是引用或指针,比如&sync.Mutex{

转载请注明出处:https://my.oschina.net/u/874727/blog/750473 Q:1025250620 非墨上一篇文文章说到:Gson通过传入的TypeToken类型,遍历Gson变量中的factorys工厂,来生成一个TypeAdapter的转换器。本章将细化这个生成过程。我们依旧沿用上一次所定义的Json对象和Java数据模型，通过一个典型的例子来学习一下：在Gson项目中,是如何做到数据适配和转换的。 // code Java public static class ClassRoom{ public String roomName; public int number; public String toString() { return "["+roomName+":"+number+"]"; } } public static class User{ public String name; public int age; private ClassRoom room; @Override public String toString() { // TODO Auto-generated method stub return name+"->"+age+":"+room; } } ... //code main String strJson = "

本文内容： LinkedHashMap概述 LinkedHashMap源码分析 LinkedHashMap概述 LinkedHashMap类似 于HashMap，区别在于采用迭代器迭代每个元素时，其顺序是按照插入次序或者是LRU次序。 其继承 关系如下： LinkedHashMap直接继承了HashMap，实现了Map接口。 LinkedHashMap用Hash存储所有元素，但迭代时却又可以按顺序遍历，这是如何做到的呢？ LinkedHashMap源码分析 看一下LinkedHashMap的属性 /** * The head of the doubly linked list. */ private transient Entry<K,V> header; /** * The iteration ordering method for this linked hash map: <tt>true</tt> * for access-order, <tt>false</tt> for insertion-order. * * @serial */ private final boolean accessOrder; 其中header列表记录着元素的插入或者LRU次序，所以很明显，LinkedHashMap能够迭代器顺序访问一定和这个header有关。其实确实是的

关于推荐引擎 如今的互联网中，无论是电子商务还是社交网络，对数据挖掘的需求都越来越大了，而推荐引擎正是数据挖掘完美体现；通过分析用户历史行为，将他可能喜欢内容推送给他，能产生相当好的用户体验，这就是推荐引擎。 推荐算法Slope one的原理 首先 Slope one是一种基于项目的协同过滤算法（ Item-based Recommendation ），简单介绍这种算法（若理解有误，欢迎大家更正， I am just a beginner ）：根据用户们对产品的喜好程度，来将产品分类；举个简单例子：比如有10个用户， 其中有9个人即喜欢产品A，也喜欢产品B，但只有2个人喜欢产品C；于是可以推断产品A和产品B是属于同类的，而产品C可能跟它们不是一类。 好了话不多讲，让我们看看Slope one吧！ Slope one是通过用户们对每个产品的评分，来计算产品间的一个差值；这种计算是通过 线性回归 f ( x ) = a x + b 到 的 ， 其中a = 1，正如它的名字Slope one（斜率为一）；另外用户的评分，在Slope one中 是必不可少的。这里举 例看看它的计算方式：下面是一张用户对书籍的评分表 书 1 书 2 书 3 用户 A 5 3 2 用户 B 3 4 未评分 用户 C 未评分 2 5 书1是否适合推荐给用户C，需要通过Slope one 计算出一个值来判定

作者： snsn1984 最近在研究QEMU，读了一些QEMU的源码，因为涉及的东西比较多，找到的资料又都比较破碎，不太完整。所以将最近的成果总结一下。 相比其他的开源软件来说，QEMU源码下面目录比较多，下面就先把这些目录的内容大致整理一下。 docs/ 包含了一些文档，说实话，对初学者来说，读这些文档压根没有头绪 hw/ 包含了所有支持的硬件设备 include/ 包含了一些头文件 linux-user/ 包含了linux下的用户模式的代码 target-XXX/ 包含了QEMU目前所支持guset端的处理器架构。包 括：alpha,arm,cris,i386,lm32,m68k,microblaze,mips,openrisc,ppc,s390x,sh4,sparc,unicore32,xtensa. 此处的XXX就是指这其中的一种架构。包含的代码的主要功能是将该guest架构的指令翻译成TCG OP代码。也就是target-arm下的代码就是将arm架构的指令翻译成TCG OP。这些目录占了源码目录的很大一部分。 tcg/ 包含了动态翻译工具tcg的源码部分，主要是将TCG OP转化为host binary的部分。这个目录下也包含了多个架构名字命名的目录，每个目录下存放着针对该架构的代码。后续会详细介绍。 test/ 从名字上可以看出，应该是存放测试部分的代码

Detect 该buildpack的探测的内容包含：容器，JRE，框架。具体内容在components.yml中可以看到： # Configuration for components to use in the buildpack --- containers: - "JavaBuildpack::Container::DistZip" - "JavaBuildpack::Container::Groovy" - "JavaBuildpack::Container::JavaMain" - "JavaBuildpack::Container::PlayFramework" - "JavaBuildpack::Container::Ratpack" - "JavaBuildpack::Container::SpringBoot" - "JavaBuildpack::Container::SpringBootCLI" - "JavaBuildpack::Container::Tomcat" # In order to use Oracle JREs instead of OpenJDK, you must comment out the OpenJDK line and uncomment the Oracle line. # Please see the documentation

bin/compile 入口是：bin/compile，该脚本和detect脚本很类似：需要一个构建目录实例化buildpack对象，并调用其compile接口。 注意：在这个脚本看似只有一个参数，但运行时实际需要第二个参数：应用缓存目录，当下载JDK， compile方法 compile mpile compile先调用component_detection，探测了对容器，JRE，framework的支持情况，并依次调用JRE的编译，每个框架的编译，和容器的编译。 Ruby代码 def compile puts BUILDPACK_MESSAGE % @buildpack_version container = component_detection( 'container' , @containers , true ).first fail 'No container can run this application' unless container component_detection( 'JRE' , @jres , true ).first.compile component_detection( 'framework' , @frameworks , false ). each (& :compile ) #调用每一个框架的编译 container.compile

上一遍源码分析，关注swift-ring-bin文件，其中最为复杂，也是最为重要操作要数rebalance方法了，它是用来重新生成ring文件，再你修改builder文件后（例如增减设备）使系统中的partition分布平衡(当然，在rebalance后，需要重新启动系统的各个服务)。其中一致性的哈希算法，副本的概念，zone的概念，weight的概念都是通过它来实现的。 源码片段： swift-ring-builder rebalance方法。 def rebalance(): """ swift-ring-builder <builder_file> rebalance Attempts to rebalance the ring by reassigning partitions that haven't been recently reassigned. """ devs_changed = builder.devs_changed #devs_changed代表builder中的devs是否改变，默认是Flase，当调用add_dev,set_dev_weight,remove_dev，会把devs_changed设置为True。 try: last_balance = builder.get_balance()#调用builder.get_balance方法

1启动界面的布局文件为app_start.xml ，对应的类文件为net.oschina.app 包下的AppStart.java。 2对于布局文件而言，因为只显示一张主题图片，因此布局简单直接设置背景图片。因为是启动界面，启动时会有短暂的卡顿，对于用户而言体验不好，因此在配置文件中自定义了style ,黑色 无标题 全屏（为什么选黑色的呢？是不是因为背景图图片是白的，衬托的更亮白呢？^_^）。设置了背景图片和无标题 <style name="Theme.AppStartLoad" parent="android:Theme.Black.NoTitleBar.Fullscreen"> <item name="android:windowBackground">@drawable/welcome</item> <item name="android:windowNoTitle">true</item> </style> 疑惑： 2.1既然已经设置了 parent="android:Theme.Black.NoTitleBar.Fullscreen"，为什么还要用 <item name="android:windowNoTitle">true</item>，另外在样式中设置了背景图片，为什么在布局文件中还要在设置下背景图片呢？难道重复的工作确实会有效的降低启动界面卡顿的问题吗？ 2

KeyValueStore 是 Ceph 支持的另一个存储引擎(第一个是FileStore)，它是在 Emporer 版本中Add LevelDB support to ceph cluster backend store Design Summit 上由本人提出并实现了原型系统，在 Firely 版本中实现了与 ObjectStore 的对接。目前已经合并到 Ceph 的 Master 上。 KeyValueStore 相对于 FileStore 是一个轻量级实现，目标是利用其不同 Backend 提供的能力来为 Ceph 的不同应用场景服务。如目前的默认 engine 是 LevelDB，期望来提供高性能的写性能。 主要数据结构 KeyValueStore 主要由三部分组成，一个是继承ObjectStore 的KeyValueStore 类，另一个是GenericObjectMap(类似于FileStore 的DBObjectMap)，最后一个是继承GenericObjectMap 的StripObjectMap。GenericObjectMap 是主要用来访问后端Engine 的实现，它的作用有点类似VFS，而Engine 就是各种不同的FileSystem，它抽象出一些基本的方法(read/write)和一些高级接口(rename/clone)等等