请注意,图表表示为邻接列表.
我听说有两种方法可以在图表中找到一个循环:
保留一个布尔值数组,以跟踪您之前是否访问过某个节点.如果你的新节点用完了(没有点击你已经存在的节点),那么只需回溯并尝试不同的分支.
来自Cormen的CLRS或Skiena的那个:对于无向图中的深度优先搜索,有两种类型的边,树和背.当且仅当存在后沿时,该图具有循环.
有人可以解释一下图的后边缘是什么,以及上述两种方法之间的差异是什么.
谢谢.
更新: 这是在两种情况下检测周期的代码.Graph是一个简单的类,为了简单起见,将所有图形节点表示为唯一编号,每个节点都有其相邻的相邻节点(g.getAdjacentNodes(int)):
public class Graph {
private int[][] nodes; // all nodes; e.g. int[][] nodes = {{1,2,3}, {3,2,1,5,6}...};
public int[] getAdjacentNodes(int v) {
return nodes[v];
}
// number of vertices in a graph
public int vSize() {
return nodes.length;
}
}
用于检测无向图中的循环的Java代码:
public class DFSCycle {
private boolean marked[];
private int s;
private Graph g;
private boolean hasCycle;
// s - starting node
public DFSCycle(Graph g, int s) {
this.g = g;
this.s = …我想Runnable通过一种方法将任务提交到ForkJoinPool:
forkJoinPool.submit(Runnable task)
注意,我使用的是JDK 7.
在引擎盖下,它们被转换为ForkJoinTask对象.我知道当一个任务以递归方式分成较小的任务时,ForkJoinPool是有效的.
题:
如果没有递归,窃取工作仍然可以在ForkJoinPool中工作吗？
在这种情况下值得吗？
更新1: 任务很小,可能不平衡.即使对于严格相同的任务,诸如上下文切换,线程调度,停车,页面未命中等事情也会妨碍导致不平衡.
更新2: Doug Lea在Concurrency JSR-166兴趣小组中写道,给出了一个暗示:
当所有任务都是异步并提交到池而不是分叉时,这也极大地提高了吞吐量,这成为构造actor框架的合理方法,以及许多您可能使用ThreadPoolExecutor的普通服务.
我认为,当涉及到相当小的CPU绑定任务时,由于这种优化,ForkJoinPool是可行的方法.重点是这些任务已经很小,不需要递归分解.工作窃取工作,无论是大型还是小型任务 - 任务都可以被来自忙碌工人的Deque尾巴的另一个自由工作者抓住.
更新3: ForkJoinPool的可扩展性 - Akka乒乓球队的基准测试显示了很好的结果.
尽管如此,要更有效地应用ForkJoinPool需要进行性能调整.
我看过一篇文章" 微服务 "由Martin Fowler,并发现它很难理解智能端点 S和哑管道.请解释这些条款,欢迎提供实例.
我将 gRPC 框架与 Proto 3 一起使用。我们有一个 java 代码覆盖工具 Jacoco，它可以扫描 java 字节代码以查找编译类中的 java“注释”@Generate，如果有，它会从覆盖范围中跳过该 java 类。但是 Proto-compiler 添加了这个注释：
@javax.annotation.Generated(
value = "by gRPC proto compiler (version 1.20.0)",
comments = "Source: myProto.proto")
public class MyClass {
...
}
但是注释 javax.annotation.Generate 有 @Retention(value=SOURCE) ，它在编译的类中不存在。
有没有办法在编译时向 protobuf 生成的 java 文件添加注释？
假设我们有一个具有20个内核的CPU和一个具有20个CPU密集型的进程,彼此独立于每个线程:每个CPU内核一个线程.我试图弄清楚在这种情况下是否发生了上下文切换.我相信这是因为操作系统中的系统进程也需要CPU时间.
我知道有不同的CPU架构,一些答案可能会有所不同,但请您解释一下:
谢谢
我已经阅读了Docker的内容,但很难找到使用Docker的真实场景？
很高兴看到你的用法.
我试图在Groovy语言中获得另一个对的列表.对只是(x,y)坐标,它们是唯一的.以下是一个简单的小例子.请注意,列表可以有几十对.
def l1 = [[x:1, y:1]]
def l2 = [[x:0, y:0]]
println l1 - l2
会得到[],这是一个空列表,但应该是这样的:[[x:1,y:1]]
更新:
for(n in l2) {
l1 = l1 - n
}
它有效,但它是一个黑魔法,并没有优化
据说:
Akka确保actor的每个实例都在自己的轻量级线程中运行,并且消息一次处理一个.
您能否解释一下在演员中一次处理一条消息的原因是什么？
为什么RESTful HTTP服务现在甚至在后端通信中如此受欢迎,除了它是一个标准和简单的？
我永远不会为需要低延迟和/或高吞吐量的后端选择HTTP-REST,主要是因为:
我可以在许多开源项目中看到RESTful Web服务,声称它们具有低延迟,高吞吐量.例如,创建RESTful微服务非常流行,将轻量级http服务器嵌入到服务器端应用程序中.
作为替代方案,我可以通过TCP使用WebSockets(当然通过HTTP升级).
我知道HTTP如何工作在底层以及下层TCP.但请解释一下,除了HTTP-REST是一个流行语和简单之外,为什么你应该使用一个,任何其他优势？