从降准谈起

考虑降准.

不能降息的原因是去杠杆.
所以只能降准.

降准释放的是流动性.

那么这个流动性的目的是什么呢?

考虑之前货币基金的快赎限额.

货基的一般标的是国债央票和一些短期债券.
赎回限额就意味着一定时期内资金总量的稳定性.

也就是投资标的成分的构成稳定性.

如果对标的是国债央票之类的货币性工具的话,那实际上只是政策导向就能基本解决的问题.
因为基本上就是利率的变动导致的变化.
而在目前利率不能往下的情况下,原则上来说是不会又什么变化需要对应的.

那么对应的应该就是这里风险级别高一些的债券.

如果发生一些异常的赎回活动,那么对应的就是这些债券的市场行为.
从基金的角度说就是需要卖出.
而对应的就是债务方的清偿压力.

因此,如果把限额的目的定义为债券稳定性的话.
换句话说就是为债券市场提供流动性支持.

而降准提供的流动性可能也就是另外一种方式而已.

反过来说,就是债券市场这块可能又一些比较不稳定或者隐性的风险性在里面.

央行发文的一个关键词是债转股.

字面意就是债券换股权.

对债务人来说,就相当于变相的债务清偿机制.
而债权人角度也只是一个财务记账名义的变更.

这似乎是一个很完美的解决方案.

不需要很复杂的系统性设计.
也不用担负触发系统性风险的问题.

问题是市场的反应.

如果市场不认可的话,那么股权价值就会降低.
对应的就是实际上的财务变更前的债务default.

所以某种程度上来说,这是在以国家信用为基础准备的对不良债务做的bailout准备.

另外一点就是提到的对小微企业的贷款融资.

这里可能存在的一个操作空间就是对于一些起来来说,不仅又bailout支持,可能还有定向的宽松支持.

这可能不是一个很好的设计.
或者说至少在目前来说,即使是定向宽松也不能保证不会对去杠杆过程产生什么负面影响.

除非是加息,提高利率.

但是单提高利率的话,也只是表面上得提升了交易成本.
而实际上,由于不动产的低流动性特征和目前的政策,维持价格水平趋势反而是一个相对容易的事情.

因为成交量放在那.

高利率就意味着高融资成本.
这个可能可以以某种政策定向缓解.

加息的另一个结果可能就是现金流动性的降低.
因为对应的是基本收益率的提高.

系统性紧缩带来的是消费的降低.
对应的是整体乘数效应的减少.
经济增长的下滑,甚至衰退.

所以,加息可能并不是一个应该马上使用的方法.

再考虑税收.

定向的减税/抵扣,尤其是针对消费性的方面的话.
也就是某种程度上的消费路径设计.

那么这里就有一个比较有趣的问题了.

给定一个消费budget,以及消费graph.
那么就存在一个算法去使得某个reward函数最大化.

而税收就是其中的regular/activate function.

所以至少从路径上来说,还处在一个相对可控的环节.

还可以通过一种市场化的计划经济方式去做一些尝试.

如果它不work呢?

那就意味着消费路径并没有按照设想中的方式展开传播.

这样的话,大概只能从semi-supervise的市场经济走向supervise的计划经济了.

人为的重构整个消费流通graph.

而这个的经验,对于一线城市来说,并不陌生.

尽管不让人舒服.
but, it works.

classloader的一些问题

前段时间写个东西遇到个情况.

大致是java中,class A extends B的话.
原则上来说A isinstanceosf B应该是返回true的.
类似的isassinablefrom应该也是返回true的.

而实际上的结果却是不预期.

这是个比较有趣的设计.

因为在jvm的实现当中,class的namespace其实是以classloader和class name共同定义的.
类似与一个classloader::class_name的定义.

实现上是klass的lookup是在symboltable的dictionary中通过hash(class_name) & classloader_data定位的.

所以这里实际上是隐式的classloader的naming isolation问题.

从隔离角度来说,这么做也不算难理解.

而且在这种情况下来说,是可以做一些比较tricky的保护机制的.
比如一些受限的class的访问.

在classloader的隔离机制下,即使能够想办法初始化出一些forbidden的类.
然后在调用的时候还是可以通过类型检查拒绝掉一部分的.

但是这样就带来一个问题.

从语义上来说,A extends B是不带有这种隔离信息暗示的.
当A B由不同的classloader定义,或者是不同的classloader环境的时候,类型系统就比较混乱了.

因为字面上的qualified name并没有完全reveal出namespace的区别.

这样的话,在写程序的时候就有比较大的心智负担.
尤其当涉及不同的classloader的instane之间做交互的时候.

而这里又有另外一个诡异的情况.

考虑来自不同classloader的A和B,且名义上A extends B.

那么,如果做cast肯定是有问题的.

但是如果做method invoke/function call的时候,又可能是没问题的.
因为在运行时或者说bytecode层面是没有type check的.

而如果这两个不同classloader的关于B的bytecode是兼容的,或者说涉及到的signature是相同的话,是没问题的.
因为算出来的dispatch table/offset是一致的.

但是如果是不兼容的,自然就又会导致运行时错误.

而顺着这个思路,对于一些restrict的环境,如果能够构造跟protected的class兼容的dispatch table的话.
理论上来说就是绕过这些限制.

比如一些加密场景.
即使密钥是安全可靠的话,也可能可以通过替换的方式绕过校验.

尤其对于校验接口是传入non primitive类型的情况.
因为这种情况下,instance的method invoke也不算是reliable的.

反过来说,如果能够完全控制某些上下游的所有涉及instance的classloader情况的话.
那至少从语法/语义层面上不存在明显的漏洞.

但这是一个相对难覆盖的问题.

因为如果能够约束class以及其所属的classloader的情况的话,也就意味这runtime是一种可追踪的情况.
如若不是的话,则无法保证某个时间点不回存在classloader泄露/逃逸的情况.
所以,在这种情况下,其实本身就已经是又一个sandbox机制去保证audit了.

有没有classloader其实关系不大.

那么为什么要设计这么一种问题比较明显的机制呢?

一种可能就是为了保证builtin class的integrity.
毕竟有个bootstrap/system classloader.

但不提供这个机制的话,也并不是不能保证完整性.

因为问题的关键不是谁load,而是load的是什么.

核心是是什么怎么定义.

类似go的method receiver和protocol的定义就比较好.

实际上就是脱离了类型这种比较古板的定义.
而是通过具有什么行为来定义区别同类.

实际上,抛开类型检查的语法和一些编译期的检查之外,运行时也基本上就是这么做的.

如果去掉这种类型系统的话,代价就是类似动态类型语言,缺少编译期的约束提醒.
以及可能对java生态更重要的类型系统的可追溯性.

这个是很多IDE和工具链所依赖的.

而如果去掉classloader的绑定的话,又为一些malicious的应用提供了一些方便.

或者从纯粹语言的角度来说,这就意味着名义上同一类型的instance,可能有着不同的行为.

而如果从contract的层面去约束class定义的话,那就意味着对于同名的class具有不同行为的场景予以拒绝.

所以,允许这种怪异行为的原因是为了使这种场景合理化么?

大概是类似于jsp这种需要code hot reload的场景.

于是一个可能比较安全的做法就是尽量去做类型的cast和从属关系判断.

非要这么做的话,可能就是需要自己做字面的递归回溯比较了.

这样至少是遵从字面语意的.