我直接好家伙，你这用框架都能推断出语言性能了

这个字段的命名 [signature] 比较合适

class Foo {
boolean signature; //boolean 类型
boolean hasSignature(){
return signature;
}
}

class Bar {
int signature; //int 类型
boolean hasSignature(){
return signature !=0 ;
}
}
学习数据库设计的正确方式把数据当成数据来看待。不要带入业务信息。业务信息由代码来控制

微服务本来也不是为了处理复用问题的
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team

Void

@djoiwhud 你看的都是什么乱七八糟的书

内存泄露是指，某个对象没用使用，没有释放内存，且随着系统运行时间增长，该对象消耗内存持续增长，最终引起系统崩溃。
如果某个对象没有使用，但是该对象使用的内存恒定。那么这个对象只是个普通的对象。

btw 我这面给你解决内存泄露的话先远离你周边的小伙伴，结交一些懂技术的就可以了

Should we use interfaces with our Service Beans?

Short answer: No.

If you want the long answer, here it is:

One of the main interests of using Spring is AOP. This is the technology that allows Spring to add new behaviors on top of your Beans: for instance, this is how transactions or security work.

In order to add those behaviors, Spring needs to create a proxy on your class, and there are two ways of creating a proxy:

If your class uses an interface, Spring will use a standard mechanism provided by Java to create a dynamic proxy.

If your class doesn’t use an interface, Spring will use CGLIB to generate a new class on the fly: this is not a standard Java mechanism, but it works as well as the standard mechanism.

Some people will also argue that interfaces are better for writing tests, but we believe we shouldn’t modify our production code for tests, and that all the new mocking frameworks (like EasyMock) allow you to create very good unit tests without any interfaces.

So, in the end, we find that interfaces for your Service beans are mostly useless, and that’s why we don’t recommend them (but we leave you with the option to generate them!).

粘一段 Jhispter 对这里的理解

还面临一众读不懂 ddd 瞎吓唬 ddd 的人，比如一楼。

另外说一下你的开源项目，现在国内市场讲究攀交情比名气。所以找个好靠山背书（比如阿里的开源）比研究这些见效快

问题挺好。但是我面试的时候从来都问我 堆、栈、算法、数据结构、图、树。卷就完了。你聊这些你不怕面试官答不上来吗？

你以为国内培训班是山寨谁的？

你现在的问题不是研究单点登录，更应该重学一遍如何造句

使用 @entity 跟 spring 的 context 一点关系都没有。

果粉急了